On 20 April 2018 at 12:25, Christoph Groth wrote:
>> Maybe not. While it would be nice to solve the loop-and-a-half
>> "problem" and the loop variable initialization "problem" (not everyone
>> agrees these are even problems, especially now that we have
>> comprehensions and generator expressions)
On 20 April 2018 at 22:52, Brett Cannon wrote:
> As an experiment we have gotten an instance of Zulip running for Python's
> development at https://python.zulipchat.com (IOW this is for discussing the
> development of Python only). As Guido has put it you can view Zulip like
> "hyper-interactive e
On 21 April 2018 at 03:30, Chris Angelico wrote:
> There's that word "readability" again. Sometimes I wish the Zen of
> Python didn't use it, because everyone seems to think that "readable"
> means "code I like".
Readability is subjective, yes. But it's not the same as "liking". If
a significant
OK, got there now. Thanks for the help. That's a lousy sign-up
experience, though...
Paul
On 21 April 2018 at 09:55, Jonathan Goble wrote:
> On Sat, Apr 21, 2018, 4:51 AM Paul Moore wrote:
>>
>> Just a usability note - the sign in procedure seems very weird. I
>> t
On 22 April 2018 at 00:05, Brett Cannon wrote:
> The Zulip project maintainers are active on our instance so after you join
> go to the Zulip stream and start a topic about this.
I did - "Zulip -> Sign up". I don't know of a way to put a link to
that topic here, but I assume it's findable in the
On 22 April 2018 at 15:39, Nick Coghlan wrote:
> On 22 April 2018 at 21:47, Paul Moore wrote:
>> On 22 April 2018 at 00:05, Brett Cannon wrote:
>>> The Zulip project maintainers are active on our instance so after you join
>>> go to the Zulip stream and start a to
On 24 April 2018 at 14:46, Nick Coghlan wrote:
> On 24 April 2018 at 23:38, Yury Selivanov wrote:
>> I propose to use the following syntax for assignment expressions:
>>
>> ( NAME = expr )
>>
>> I know that it was proposed before and this idea was rejected, because
>> accidentally using '=' i
On 24 April 2018 at 15:58, Yury Selivanov wrote:
> On Tue, Apr 24, 2018 at 10:49 AM, Paul Moore wrote:
> [..]
>>>> 3. Most importantly: it is *not* allowed to mask names in the current
>>>> local scope.
>>>
>>> While I agree this would be unambiguo
I see no practical benefit to making such a restriction, and there's a
risk of breaking existing code.
While it's not something I've ever used myself in real code,
def wrapper(*args, **kw):
return wrapped_fn(some_arg=1, *args, **kw)
seems like a perfectly reasonable way to write a wr
On 28 April 2018 at 05:08, Nick Coghlan wrote:
> On 28 April 2018 at 12:34, Guido van Rossum wrote:
>>
>> Um, the PEP has "Unix-Like Systems" in its heading, so discussing the
>> Windows situation seems out of scope to me.
>
> Sorry, I conflated two issues there - while PEP 394 itself is specific
On 30 April 2018 at 17:37, Steven D'Aprano wrote:
> On Mon, Apr 30, 2018 at 08:09:35AM +0100, Paddy McCarthy wrote:
> [...]
>> A PEP that can detract from readability; *readability*, a central
>> tenet of Python, should
>> be rejected, (on principle!), when such objections are treated so
>> dismi
On 2 May 2018 at 22:37, Antoine Pitrou wrote:
> To elaborate a bit: the OP, while angry, produced both a detailed
> analysis *and* a PR. It's normal to be angry when an advertised
> feature doesn't work and it makes you lose hours of work (or, even,
> forces you to a wholesale redesign). Producin
On 3 May 2018 at 03:26, Steven D'Aprano wrote:
>> Will all due respect, it's sometimes unpredictable what kind of wording
>> Anglo-Saxons will take as an insult, as there's lot of obsequiosity
>> there that doesn't exist in other cultures. To me, "not give a damn"
>> reads like a familiar version
On 16 May 2018 at 05:35, Alex Walters wrote:
> In the spirit of learning why there is a fence across the road before I tear
> it down out of ignorance [1], I'd like to know the rationale behind source
> only releases of cpython. I have an opinion on their utility and perhaps an
> idea about chang
On 16 May 2018 at 09:34, Serhiy Storchaka wrote:
> 16.05.18 07:35, Alex Walters пише:
>>
>> [1]: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
>
>
> And I wish that every author who suggested the idea for Python was familiar
> with the Chesterton's fence principle.
Agreed - thanks
On 17 May 2018 at 04:46, Alex Walters wrote:
>> 1. Producing binaries (to the quality we normally deliver - I'm not
>> talking about auto-built binaries produced from a CI system) is a
>> chunk of extra work for the release managers.
>
> This is actually the heart of the reason I asked the questio
On 17 May 2018 at 14:42, Brett Cannon wrote:
>
> If I understand things correctly, our planned migration to VSTS will include
> eventually automating the signing of the Windows releases so that part wont
> be an issue (which are currently signed manually be Steve).
Somewhat off-topic for this dis
On 21 May 2018 at 13:41, Serhiy Storchaka wrote:
> Please don't forgot to perform the following steps when add a new public C
> API:
>
> * Document it in Doc/c-api/.
>
> * Add an entry in the What's New document.
>
> * Add it in Doc/data/refcounts.dat.
>
> * Add it in PC/python3.def.
I thought p
On 21 May 2018 at 14:42, Serhiy Storchaka wrote:
>> Is it even acceptable to add a symbol into the limited ABI? I thought
>> the idea was that if I linked with python3.dll, my code would work
>> with any version of Python 3? By introducing new symbols, code linked
>> with the python3.dll shipped w
On 22 May 2018 at 18:00, Steve Dower wrote:
> On 21May2018 0708, Paul Moore wrote:
>>
>> On 21 May 2018 at 14:42, Serhiy Storchaka wrote:
>>>>
>>>> Is it even acceptable to add a symbol into the limited ABI? I thought
>>>> the idea was th
On 23 May 2018 at 09:14, Antoine Pitrou wrote:
> On Tue, 22 May 2018 19:10:49 -0500
> Tim Peters wrote:
>
>> Thanks for that! It instantly cleared up several mysteries for me.
>> I'm just starting to learn git & github, and am starkly reminded of an
>> old truth: there is absolutely nothing "ob
On 22 June 2018 at 20:17, Ivan Pozdeev via Python-Dev
wrote:
> On 22.06.2018 22:07, Terry Reedy wrote:
>> https://docs.python.org/3/library/collections.abc.html#collections-abstract-base-classes
>>
>> says that a Sequence has both __getitem__ and __len__.
>>
>> I am surprised that a C-API functio
On 22 June 2018 at 23:21, Brett Cannon wrote:
> Thanks to a PR from Ammar Askar we now run Python under lcov as part of the
> code coverage build. And thanks to codecov.io automatically merging code
> coverage reports we get a complete report of our coverage (the first results
> of which can now b
On 25 June 2018 at 12:44, Nick Coghlan wrote:
> Unfortunately, I think the key rationale for (b) is that if you
> *don't* do something along those lines, then there's a different
> strange scoping discrepancy that arises between the non-comprehension
> forms of container displays and the comprehen
On 25 June 2018 at 13:17, Nick Coghlan wrote:
> On 25 June 2018 at 09:25, Guido van Rossum wrote:
>> A "neutral" argument about (b) is that despite the "horrified" reactions
>> that Nick saw, in practice it's going to confuse very few people (again, due
>> to my point about Python's scope rules).
On 25 June 2018 at 13:24, Nick Coghlan wrote:
> On 25 June 2018 at 22:17, Nick Coghlan wrote:
>> FWIW, the most cryptic parent local scoping related exception I've
>> been able to devise so far still exhibits PEP 572's desired "Omitting
>> the comprehension scope entirely would give you the same
On 27 June 2018 at 07:54, Steven D'Aprano wrote:
> Comprehensions already run partly in the surrounding scope.
>
> I tried to take a survey of people on the Python-List mailing list, so
> see what their expectations of comprehension scope was. Disappointingly,
> not many people responded, but thos
On 27 June 2018 at 08:52, Chris Angelico wrote:
> On Wed, Jun 27, 2018 at 5:30 PM, Paul Moore wrote:
>> But test() returns [1, 2]. So does that say (as you claim above) that
>> "the comprehension ran in the enclosing scope"? Doesn't it just say
>> tha
On 27 June 2018 at 15:39, Nick Coghlan wrote:
> However, PEP 572 in its current form takes the position "parent local
> scoping is sufficiently useful to make it a required pre-requisite for
> adding assignment expressions, but not useful enough to expose as a
> new scope declaration primitive",
On 25 May 2015 at 21:06, MRAB wrote:
> As the subject says, I've been unable to build the regex module against
> Python 3.5b1 for 32-bit. MingGW says:
>
> skipping incompatible .../libpython35.a when searching for -lpython35
>
> It builds without a problem against Python 3.5 for 64-bit.
>
> An
On 26 May 2015 at 00:34, MRAB wrote:
> The 32-bit Python says it's 32-bit and the 64-bit Python says it's 64-bit.
>
> ---8<---
>
> C:
>
> rem Compile for Python 3.5 (64-bit) [works]
> cd C:\MinGW64\bin
> "C:\MinGW64\bin\gcc.exe" -mdll -m64 -DMS_WIN64 -O2 -Wall -Wsign-compare
> -Wconversion -I"C:\P
On 26 May 2015 at 07:49, Paul Moore wrote:
> Do you get the same failure when using distutils to build the extension?
Hmm, I just checked and it seems that only Python 3.5 ships
libpythonXY.a by default - 3.4 and earlier (at least on my machine)
don't have it. Presumably you gene
On 26 May 2015 at 13:55, Steve Dower wrote:
> The builds I am responsible for include it because someone reported an issue
> and was persistent and helpful enough that I fixed it for them.
>
> That said, until MinGW agrees on a stable branch/version/fork, there seems
> to be a good chance that the
On 26 May 2015 at 18:23, MRAB wrote:
> I made libpython35.a like I did for the others and it's all working now. All
> the tests pass. :-)
Cool. How did you make libpython35.a? Sounds like there is some
difference in the process being used for the shipped version.
Paul
___
On 27 May 2015 at 03:02, MRAB wrote:
> When I tried:
>
> C:\MinGW64\bin\dlltool.exe
>
> or:
>
> C:\MinGW64\x86_64-w64-mingw32\bin\dlltool.exe
>
> for the 32-bit builds, they wouldn't link.
Was that with "-m i386"? If so, then I suspect that's the issue.
Steve, did you use 64-bit mingw to
On 27 May 2015 at 09:10, Nick Coghlan wrote:
> The old distutils docs aren't gone, the top level links just moved to the
> distutils package docs: https://docs.python.org/3/library/distutils.html
>
> I kept them (with the same deep link URLs) because I know there's stuff in
> there that isn't curr
With Python 3.5 shipping an embeddable copy of the interpreter on
Windows, I thought I'd try out a simple embedded interpreter as an
experiment. I wanted to use the limited API, as I'd rather it were
easy to upgrade the interpreter without recompiling the embedding app.
But the "Very high-level em
On 28 May 2015 at 15:37, Donald Stufft wrote:
> I think docker is a pretty crummy answer to Go’s static binaries. What I would
> love is for Python to get:
>
> * The ability to import .so modules via zipzimport (ideally without a
> temporary
> directory, but that might require newer APIs from l
On 28 May 2015 at 15:28, Steve Dower wrote:
> I don't have the issue number handy, but it should be near the top of the
> recently modified list.
I recall seeing that issue. I'm fine with that - getting the two in
sync is obviously worth doing (and clearly in hand). I'm personally
not sure whethe
On 28 May 2015 at 16:58, Barry Warsaw wrote:
> On May 28, 2015, at 11:39 AM, Donald Stufft wrote:
>
>>You don’t need a "fully functioning Python" for a single file binary, you
>>only need enough to actually run your application. For example, if you're
>>making an application that can download file
On 28 May 2015 at 17:28, Chris Barker wrote:
> On Thu, May 28, 2015 at 9:23 AM, Chris Barker wrote:
>>
>> Barry Warsaw wrote:
>> >> I do think single-file executables are an important piece to Python's
>> >> long-term competitiveness.
>>
>> Really? It seems to me that desktop development is dying
On 28 May 2015 at 17:13, Barry Warsaw wrote:
> On May 28, 2015, at 10:37 AM, Donald Stufft wrote:
>
>>I think docker is a pretty crummy answer to Go’s static binaries. What I would
>>love is for Python to get:
>>
>>* The ability to import .so modules via zipzimport (ideally without a
>>temporary
On 28 May 2015 at 17:47, Guido van Rossum wrote:
> Single-file binaries are indeed important. (Though in most cases they don't
> have to be totally stand-alone -- they can depend on a system python and its
> stdlib. At least in typical datacenter setups.) Have people looked at PEX (a
> format deve
On 28 May 2015 at 18:04, Brian Curtin wrote:
> Donald mentioned one earlier: command line utilities. I want a single
> CLI I can deploy to my customers that doesn't make them have to
> install Python or even know it's Python at all.
Yep, that's the killer for me as well.
I know it's unrealistic
On 28 May 2015 at 19:22, Chris Angelico wrote:
>> Unfortunately (and believe me, I've been down this road many times) on
>> Windows *only* the exe format is a "first-class" executable.
>> Executable scripts and shebangs are very useful, but there are always
>> corner cases where they don't work *q
On 28 May 2015 at 20:47, Brett Cannon wrote:
> I think it's to have a single tool to do it for any platform, not to have
> the technical nuts and bolts be the same necessarily. I think it's also to
> figure out if there is anything the interpreter and/or stdlib can do to
> facilitate this.
Precis
On 29 May 2015 at 09:36, Steven D'Aprano wrote:
> The point is, in the Linux circles I move in, this idea of single file
> installation would be about as popular as a police raid at a rave club.
> Maybe you move in different circles (perhaps more enterprisey?), but I
> can already imagine the sort
On 28 May 2015 at 22:09, Glenn Linderman wrote:
> This would be something I could use and benefit from immediately upon it
> being available, so I laud your idea, and hope you have a successful
> implementation, and look forward to using it. It would largely replace the
> need for the py.exe laun
On 29 May 2015 at 21:49, Glenn Linderman wrote:
>
> That looks interesting, I wonder what compilation environment it would need?
> I don't think I've even installed a C compiler on my last couple boxes, and
> the only version of a C compiler I have is, umm... M$VC++6.0, since I've
> moved to using
On 29 May 2015 at 23:15, Glenn Linderman wrote:
> I don't presently see any C:\Python34\DLLs or C:\Python34 on my path, but I
> didn't ask the installer to put it there either. So I'm guessing your option
> 1 assumes asking the Python installer to put it there? Not "automatically"
> but "on reques
On 31 May 2015 at 10:14, Xavier Combelle wrote:
>> +1. The new embeddable Python distribution for Windows is a great step
>> forward for this. It's not single-file, but it's easy to produce a
>> single-directory self-contained application with it. I don't know if
>> there's anything equivalent for
On 31 May 2015 at 11:41, Paul Moore wrote:
> On 31 May 2015 at 10:14, Xavier Combelle wrote:
>>> +1. The new embeddable Python distribution for Windows is a great step
>>> forward for this. It's not single-file, but it's easy to produce a
>>> single-dire
I'm trying to script a command line uninstall of Python 3.5. The new
installer has a nice well-documented command line interface, but
there's nothing much about how to uninstall.
Looking at the installed products, I see
>get-wmiobject Win32_Product -filter 'name like "Python 3.5.0b2%"' | select N
On 1 June 2015 at 20:21, Steve Dower wrote:
> You need the original exe and can pass /uninstall to that.
OK, that's cool. Looks like I missed that in the docs. (Checks) Yes, I did :-(
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.
On 5 June 2015 at 02:28, MRAB wrote:
> For reference, here's how I can build the regex module on Windows 8.1,
> 64-bit, using only MinGW64.
>
> For Python 3.5, I can link against "python35.dll", but for earlier
> versions, including Python 2.7, I need "libpython.a".
>
> I have built regex module f
On 14 July 2015 at 14:51, Florian Bruhin wrote:
> * Steven D'Aprano [2015-07-14 23:41:56 +1000]:
>> On Tue, Jul 14, 2015 at 02:06:14PM +0200, Dima Tisnek wrote:
>> > https://bugs.python.org/issue21238 introduces detection of
>> > missing/misspelt mock.assert_xxx() calls on getattr level in Python
On 14 July 2015 at 20:27, Robert Collins wrote:
> Well.
>
> I'd go further and just separate the APIs.
>
> mock.assert_called_with(a_mock, *args, **kwargs)
>
> mock can know how to poke under the covers (e.g. using
> __Mock_assert_called_with) without leaking it into the users objects.
As someone
On 20 July 2015 at 08:15, Stephen J. Turnbull wrote:
> Every one needs to be considered carefully,
It's very hard to pick out snippets like this out of context,
particularly in a thread that has already caused a lot of turmoil, but
I think this point is worth addressing. And my apologies in advan
On 20 July 2015 at 13:34, Ben Finney wrote:
>> Again, I'm sorry to pick on one sentence out of context, but it cut
>> straight to my biggest fear when doing a commit (on any project) -
>> what if, after all the worrying and consideration I put into doing
>> this commit, people disagree with me (or
On 21 July 2015 at 11:03, Ben Finney wrote:
> * If challenged to do so, could one (the contributor) present a
> compelling justification for the change?
>
> This is what I claim Paul Moore's doubt (fear?) is indicative of. I
> maintain that this doubt is quite healthy: it helps the contribut
On 22 July 2015 at 03:18, Stephen J. Turnbull wrote:
> The only *practical* suggestion from "the core" has been self-
> restraint on the part of "the crowd"
I would have said the following has been covered, but maybe not. At
the risk of repeating something that's already been said, here are
some
On 21 July 2015 at 18:06, Carol Willing wrote:
> The Communications Quick Start section would be brief and practical much
> like the Quick Start section for downloading and testing the source code.
> Placing the Communications Quick Start section before the existing Quick
> Start section would emp
On 22 July 2015 at 12:09, Paul Moore wrote:
> 5. Assume that the decision was well-considered and made with good
> reasons. If you don't understand the reasons, and feel you need to,
> ask for them, but refrain from judgement until you have the reasons.
> The original mail in
On 23 July 2015 at 03:01, Alexander Belopolsky
wrote:
> On Wed, Jul 22, 2015 at 7:09 AM, Paul Moore wrote:
>>
>> does anyone seriously think a core dev
>> commits code as a joke???
>
>
> Yes, <https://hg.python.org/cpython/rev/0530aadff696>. :-)
Second pe
On 25 July 2015 at 20:28, Robert Collins wrote:
> Those charts doesn't show patches in 'commit-review' -
> http://bugs.python.org/issue?%40columns=title&%40columns=id&stage=5&%40columns=activity&%40sort=activity&status=1&%40columns=status&%40pagesize=50&%40startwith=0&%40sortdir=on&%40action=searc
On 26 July 2015 at 16:39, Berker Peksağ wrote:
>> I'm not actually clear what "Commit Review" status means. I did do a
>> quick check of the dev guide, and couldn't come up with anything,
>
> https://docs.python.org/devguide/triaging.html#stage
Thanks, I missed that. The patches I checked seemed
On 26 July 2015 at 16:33, Nick Coghlan wrote:
> As a user, if the apparent semantics of time zone aware date time
> arithmetic are accurately represented by "convert time to UTC ->
> perform arithmetic -> convert back to stated timezone", then I *don't
> care* how that is implemented internally.
>
On 27 July 2015 at 08:34, Lennart Regebro wrote:
> On Mon, Jul 27, 2015 at 9:09 AM, Tim Peters wrote:
>> But for a dozen years it's sufficed to do what Paul did.
>
> No, it never did "suffice". It's just that people have been doing
> various kinds of workarounds to compensate for these design fla
On 27 July 2015 at 09:54, Lennart Regebro wrote:
> On Mon, Jul 27, 2015 at 10:47 AM, Paul Moore wrote:
>> I'm confused by your position. If it's 7am on the clock behind me,
>> right now, then how (under the model proposed by the PEP) do I find
>> the datetime val
On 27 July 2015 at 14:59, R. David Murray wrote:
> I have a feeling that I'm completely misunderstanding things, since
> tzinfo is still a bit of a mystery to me.
You're not the only one :-)
I think the following statements are true. If they aren't, I'd
appreciate clarification. I'm going to com
On 27 July 2015 at 15:37, Lennart Regebro wrote:
> That you add one hour to it, and the datetime moves forward one hour
> in actual time? That's doable, but during certain circumstance this
> may mean that you go from 1AM to 1AM, or from 1AM to 3AM.
>
> Or do you expect that adding one hour will i
On 27 July 2015 at 16:26, MRAB wrote:
>> Note that I'm not talking about internal representations - this is
>> purely about user-visible semantics.
>>
> Would it help if it was explicit and we had LocalDateTime and
> UTCDateTime?
I don't see how. Why should I care about the internal representatio
On 27 July 2015 at 17:30, Lennart Regebro wrote:
>> Apologies for asking yet another dumb question about this, but I have
>> the impression that a lot of other people are struggling with the basics
>> here too.
>>
>> Can you tell us which of the two operations datetime currently
>> implements?
>
>
On 27 July 2015 at 15:57, Ronald Oussoren wrote:
> IMHO “+ 1 days” and “+ 24 hours” are two different things. Date
> arithmetic is full of messy things like that. “+ 1 month” is another
> example of that (which the datetime module punts completely
> and can be a source of endless bikeshidding).
On 27 July 2015 at 22:10, Tim Peters wrote:
>> 1. Converting to and from them. That's messy because the conversion to
>> UTC needs more information than just the date & time (typically, for
>> example, there is a day when 01:45:00 maps to 2 distinct UTC times).
>> This is basically the "is_dst" bi
On 28 July 2015 at 05:18, Ben Finney wrote:
>
> Indeed, these non-rational ways of reaching a decision are essential to
> allow us to act with any kind of speed. Non-rational decision making is
> much faster, and necessarily will form the great majority of our
> decision making. Good!
>
> What I'm
On 28 July 2015 at 13:35, Ben Finney wrote:
> People can, do, and probably must make many decisions through
> non-rational processes. I don't propose to change that.
Good.
> Choices can be made that, when challenged, lack compelling rational
> justification. I do propose that such a challenge sh
On 8 August 2015 at 04:53, Nick Coghlan wrote:
>> I do however think it would make ensurepip itself better, so I’m not dead
>> set against it, mostly just worried about ramifications.
>
> I'd advise against letting concerns about Linux distro politics hold
> you back from making ensurepip as good
On 8 August 2015 at 02:39, Eric V. Smith wrote:
> Following a long discussion on python-ideas, I've posted my draft of
> PEP-498. It describes the "f-string" approach that was the subject of
> the "Briefer string format" thread. I'm open to a better title than
> "Literal String Formatting".
>
> I
On 17 August 2015 at 05:34, Victor Stinner wrote:
> 2015-08-16 7:21 GMT-07:00 Paul Moore :
>> 2. By far and away the most common use for me would be things like
>> print(f"Iteration {n}: Took {end-start) seconds"). At the moment I use
>> str,format() for this, an
On 17 August 2015 at 12:48, Larry Hastings wrote:
> I think this corner of the debate is covered by the "Consenting adults"
> guiding principle we use 'round these parts.
Precisely.
Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyt
On 28 August 2015 at 00:25, Nick Coghlan wrote:
> I'd suggest including a clearer motivation there:
>
> Note: The asyncio package has been included in the standard
> library on a provisional basis, and thus may gain new APIs and
> capabilities in maintenance releases as it matures. Backwards
>
On 28 August 2015 at 10:46, Gustavo Carneiro wrote:
> I think this is a packaging problem.
>
> In an ideal world, Python would ship some version of asyncio, but you would
> also be able to pip install a newer version into your virtual environment,
> and it would override the version in stdlib.
>
>
On 1 September 2015 at 17:15, Steve Dower wrote:
> On 01Sep2015 0747, Oscar Benjamin wrote:
>>
>> Thanks for the detailed writeup Steve. Do you know how these changes
>> to the python.org Windows binaries would impact on people building
>> extension modules with MinGW?
>
>
> Currently, no version
On 2 September 2015 at 13:01, Carl Kleffner wrote:
> that is https://bugs.python.org/msg248716 see also
> http://rt.openssl.org/Ticket/Display.html?id=3390&user=guest&pass=guest
Interesting. But it does confirm that object files have to be rebuilt,
and there's no way to use existing object files.
On 2 September 2015 at 14:07, Steve Dower wrote:
> You can also build existing object or static libraries into their own DLL
> with the old compiler and dynamically link to them. It's not perfect, but
> it's no worse than trying to link them in directly.
Interesting approach. "gcc -shared -o xpm.
On 8 September 2015 at 15:12, Gary Robinson wrote:
> So, one thing I am hoping comes out of any effort in the “A better story”
> direction would be a way to share large data structures between processes.
> Two possible solutions:
>
> 1) More the reference counts away from data structures, so cop
First of all, an apology. I know this is probably going to be of
limited interest for many on python-dev, but I'm honestly not sure
where there's a better audience for the question. As it's related to
how people should use the new "embeddable" distribution of Python 3.5,
I'm hoping it's sufficientl
On 9 September 2015 at 16:11, Carl Kleffner wrote:
> A good overview on this topic is given on
> https://github.com/numpy/numpy/wiki/windows-dll-notes. As a side note the
> PATH is usually the latest place in the search order of DLLs. Pre-loading
> python35.dll into the process space from within v
On 9 September 2015 at 17:16, Steve Dower wrote:
> Don't bother reading into SxS assemblies. It may work, but it will destroy
> more brain cells than are worth wasting on it. :)
:-) Yeah, I looked at SxS once before and sprained my brain. But the
summary on the numpy wiki looked like a digestible
On 16 September 2015 at 06:10, Stephen J. Turnbull wrote:
> The only thing that hg really lost badly on
> IMO was "named branches", and that's been fixed with bookmarks.
FWIW, I still find bookmarks confusing to use compared to git
branches. I don't know whether that's because bitbucket doesn't
On 16 September 2015 at 17:10, Nikolaus Rath wrote:
>> I don't know of an equivalent of remote tracking branches in
>> Mercurial. Maybe bookmarks work that way by default?
>
> Where exactly did you run into problems? I think you should have gotten
> the same result with the following hg commands (
On 19 September 2015 at 10:12, Sven R. Kunze wrote:
> The only question I have: is there a particular reason (not technical one)
> why there are many pips on my PC?
That's not an unreasonable question, but (IMO) most of the answers are
technical, or amount to "why would you think that's wrong". S
On 19 September 2015 at 06:49, Terry Reedy wrote:
> On 9/19/2015 1:24 AM, Stephen J. Turnbull wrote:
>>
>> Barry Warsaw writes:
>>
>> > One thing that came up in a similar discussion is pip, and the
>> > suggested move to `python -m pip`, which makes a lot of sense.
>> > However, *inside* a
On 19 September 2015 at 18:15, Sven R. Kunze wrote:
>> So, to directly answer:
>>
>> Because there are technical challenges that no-one has stepped up to
>> solve.
>
>
> Let's solve them. :)
I thought my point was "yes, go for it - your code contribution would
be appreciated" :-)
Paul
__
On 19 September 2015 at 19:37, Brett Cannon wrote:
> Guys, this thread is about removing the pyvenv script, not pip. If you want
> to start a discussion about pip and its command structure that should
> probably happen on pip's issue tracker or over at distutils-sig.
Sorry, good point.
Back to t
On 28 September 2015 at 21:18, MRAB wrote:
> Same here. I compile the regex module for Python 2.5-2.7 and 3.1-3.5,
> both 32-bit and 64-bit, using MinGW-w64, and I haven't had a problem yet
> that wasn't due to a bug in the source code.
Interesting. With Python 3.5, what CRT does the module use?
On 28 September 2015 at 22:18, Nathaniel Smith wrote:
> On Sep 28, 2015 1:39 PM, "Paul Moore" wrote:
>>
>> On 28 September 2015 at 21:18, MRAB wrote:
>> > Same here. I compile the regex module for Python 2.5-2.7 and 3.1-3.5,
>> > both 32-bit and 6
On 25 September 2015 at 16:35, INADA Naoki wrote:
> You can use "Windows SDK for Windows 7 and .NET Framework 4".
>
> http://www.microsoft.com/en-us/download/details.aspx?id=8279
>
> On Sat, Sep 26, 2015 at 12:24 AM, Chris Barker - NOAA Federal
> wrote:
>>
>> As I understand it, the MS VS2010 com
On 30 September 2015 at 01:31, Chris Barker - NOAA Federal
wrote:
> It may be -- I've still have to test. Neither Windows nor py3 are my
> primary production versions.
Part of the problem here is that people put up postings saying "do
this" having checked that it works for them, and then others s
301 - 400 of 1862 matches
Mail list logo
