On 2 February 2012 03:47, Nick Coghlan wrote:
> Rather than being timestamp specific, such a protocol would be a
> general numeric protocol. If (integer, numerator, denominator) is used
> (i.e. a "mixed number" in mathematical terms), then "__from_mixed__"
> would be an appropriate name. If (integ
On 2 February 2012 12:16, Victor Stinner wrote:
> Let's take an NTP timestamp in format (c): (sec=0,
> floatpart=1, divisor=2**32):
>
Decimal(1) * Decimal(10)**-10
> Decimal('0.01')
Decimal(1) / Decimal(2)**32
> Decimal('0.023283064365386962890625')
>
> Yo
On 3 February 2012 19:18, Yury Selivanov wrote:
> That's a bit far-fetched. Using same level argumentation we can utilize
> even `0`. `raise e from 0` (or `-1`), and use `0` object instead of
> Ellipsis.
>
> Anyways, if the PEP is not yet fully approved, I'm minus one on allowing
> of using anyt
On 4 February 2012 11:25, Steven D'Aprano wrote:
> It strikes me that it would be helpful sometimes to programmatically
> recognise "preview" modules in the std lib. Could we have a recommendation
> in PEP 8 that such modules should have a global variable called PREVIEW, and
> non-preview modules
On 7 February 2012 20:49, Antoine Pitrou wrote:
> Well, import time is so important that the Mercurial developers have
> written an on-demand import mechanism, to reduce the latency of
> command-line operations.
One question here, I guess - does the importlib integration do
anything to make writi
On 8 February 2012 09:49, Eli Bendersky wrote:
>> I concur. It's important that we consider Fredrik's ownership of the
>> modules, but if he fails to reply to email and doesn't update his
>> repositories, there should be enough cause for python-dev to go on and
>> appropriate the stdlib versions o
On 8 February 2012 12:21, Nick Coghlan wrote:
> On Wed, Feb 8, 2012 at 10:04 PM, Antoine Pitrou wrote:
>> On Wed, 8 Feb 2012 11:11:07 +0000
>> Paul Moore wrote:
>>> It's important to respect Fredrik's wishes and ownership, but we can't
>>> le
On 19 February 2012 03:09, Mark Hammond wrote:
> Thanks for the note Paul, but did you also mean to CC python-dev?
Yes, I did, sorry.
>
> On 18/02/2012 9:15 PM, Paul Moore wrote:
>>
>> On 18 February 2012 05:24, Mark Hammond wrote:
>>>
>>> I'm wonder
On 19 February 2012 13:04, Stefan Behnel wrote:
> When compiling for PyPy, Cython therefore needs a way to tell PyPy about
> any changes. For the tstate->curexc_* fields, there are the two functions
> PyErr_Fetch() and PyErr_Restore(). Could we have two similar "official"
> functions for the exc_*
On 26 February 2012 12:34, Eli Bendersky wrote:
> On Sun, Feb 26, 2012 at 12:33, pmon mail wrote:
>> Documentation clearly states that the 'L' is a 4 byte integer.
>>
>> Is this a bug? I'm I missing something?
>>
>
> By default pack uses native size, not standard size. On a 64-bit machine:
As th
On Sun, Feb 26, 2012 at 3:16 PM, Eli Bendersky wrote:
> 7.2.3.1 says, shortly after the first table:
>
> "
>
> Native size and alignment are determined using the C compiler’s sizeof
> expression. This is always combined with native byte order.
>
> Standard size depends only on the format character
On 26 February 2012 13:41, Antoine Pitrou wrote:
>> We have several options with regard to 2.7 and 3.2:
>>
>> 1) Won't fix.
>
> Given the extent of the rewrite, this one has my preference.
+1 (although I'd word it as "fixed in 3.3" rather than "won't fix").
Paul.
__
On 27 February 2012 20:39, Chris McDonough wrote:
> Note that u'' literals are sort of the tip of the iceberg here;
> supporting them will obviously not make development under the subset an
> order of magnitude less sucky, just a tiny little bit less sucky. There
> are other extremely annoying th
On 28 February 2012 12:07, Mark Shannon wrote:
>>> frozendict helps also in threading and multiprocessing.
>>
>> How so?
>
> Inter process/task communication requires copying. Inter/intra thread
> communication uses reference semantics. To ensure these are the same,
> the objects used in communica
On 29 February 2012 19:17, Raymond Hettinger
wrote:
> From this experience, I conclude that adding a frozendict type
> would be a total waste (except that it would inspire more people
> to request frozen variante of other containers).
It would (apparently) help Victor to fix issues in his pysandb
On 1 March 2012 12:08, Victor Stinner wrote:
> New try:
>
> "A frozendict is a read-only mapping: a key cannot be added nor
> removed, and a key is always mapped to the same value. However,
> frozendict values can be mutable (not hashable). A frozendict is
> hashable and so immutable if and only i
On 1 March 2012 12:37, Yury Selivanov wrote:
> Actually I find fronzendict concept quite useful. We also have an
> implementation in our framework, and we use it, for instance, in
> http request object, for parsed arguments and parsed forms, which
> values shouldn't be ever modified once parsed.
On 1 March 2012 17:44, Victor Stinner wrote:
> I challenge anyone to try to break pysandbox!
Can you explain precisely how a frozendict will help pysandbox? Then
I'll be able to beat this challenge :-)
Paul.
___
Python-Dev mailing list
Python-Dev@pyth
On 7 March 2012 23:05, Brett Cannon wrote:
> At the language summit today I got clearance to merge my importlib bootstrap
> branch (http://hg.python.org/sandbox/bcannon#bootstrap_importlib) thanks to
> performance being about 5% slower using the normal_startup (which, as Thomas
> Wouters said, is
On 8 March 2012 12:52, Nick Coghlan wrote:
> 2. it's already trivial to achieve such chained lookups in 3.3 by
> passing a collections.ChainMap instance as the globals parameter:
> http://docs.python.org/dev/library/collections#collections.ChainMap
Somewhat OT, but collections.ChainMap is really
On 13 March 2012 03:48, C. Titus Brown wrote:
> I feel like there's a middle ground where stable, long-term go-to modules
> could
> be mentioned, though. I don't spend a lot of time browsing PyPI, but I
> suspect
> almost everyone spends a certain amount of time in the Python docs (which is a
>
On 13 March 2012 13:34, Donald Stufft wrote:
> http://python-guide.org ?
Hmm, yes maybe. I had seen this before (it's where I found out about
requests, IIRC).
As it says, it "is mostly a skeleton at the moment". With some
fleshing out, then it's probably a good start. I have some problems
with
On 15 March 2012 01:58, Matt Joiner wrote:
> Victor, I think that steady can always be monotonic, there are time sources
> enough to ensure this on the platforms I am aware of. Strict in this sense
> refers to not being adjusted forward, i.e. CLOCK_MONOTONIC vs
> CLOCK_MONOTONIC_RAW.
I agree - Kr
On 15 March 2012 10:06, Matt Joiner wrote:
>> I'm baffled as to how you even identify "forward leaps". In relation
>> to what? A more accurate time source? I thought that by definition
>> this was the most accurate time source we have!
>
> Monotonic clocks are not necessarily hardware based, and m
On 15 March 2012 12:12, Nadeem Vawda wrote:
> On Thu, Mar 15, 2012 at 1:10 PM, Paul Moore wrote:
>> I appreciate that. But I'm still unclear how you would tell that had
>> happened as part of the implementation. One call to the OS returns
>> 12345. The next returns
On 16 March 2012 00:12, Carl Meyer wrote:
> Changing the directory name is in fact a new and different (and much
> more invasive) special case, because distutils et al install scripts
> there, and that directory name is part of the distutils install scheme.
> Installers don't care where the Python
On 16 March 2012 15:17, Lindberg, Van wrote:
> This is not a "we should be consistent" argument - I know that would
> never fly. I do cross-platform dev all the time (develop on Windows and
> Mac, deploy on Linux) and so this bites me *every single time* I want to
> get a consistent layout between
On 17 March 2012 05:28, Mark Hammond wrote:
>> I hate to seem like I'm piling on now after panning your last brainstorm
>> :-), but... this would be quite problematic for virtualenv users, many
>> of whom do rely on the fact that the virtualenv "stuff" is confined to
>> within a limited set of kn
On 17 March 2012 14:07, Serhiy Storchaka wrote:
> 17.03.12 13:57, Paul Moore написав(ла):
>
>> As there is no
>> way of knowing the Python version without running Python, this is too
>> slow to be practical.
>
>
> Cold start:
> $ time python3 --version
> P
On 20 March 2012 14:08, Lindberg, Van wrote:
> On 3/20/2012 5:48 AM, Mark Hammond wrote:
>> While I'm still unclear on the actual benefits of this, Martin's
>> approach strikes a reasonable compromise so I withdraw my objections.
>
>
> Ok. I was out of town and so could not respond to most of the
On 20 March 2012 14:27, VanL wrote:
> Germane to this discussion, I reached out for feedback. Most people didn't
> care about the issue, or were slightly inclined to have it be uniform across
> platforms.
>
> As Terry mentioned, I think that long-term uniformity will benefit everybody
> down the l
On 20 March 2012 19:35, Lindberg, Van wrote:
> I would like to know if you would object to user lib installs matching
> the system install. I.e., would it cause problems with you if it were
> just 'lib' everywhere, with no 'lib/python{version}'? It sounded like
> adding the version directory was t
On 20 March 2012 19:22, VanL wrote:
> There are a number of casual users that probably only have one version
> installed, but every python user/dev on windows that I know has one python
> that they consider to be "python," and everything else needs to be launched
> with a suffix (e.g., python26.ex
On 20 March 2012 22:00, VanL wrote:
> On 3/20/2012 4:49 PM, Mark Hammond wrote:
>>
>> So I'm assuming that:
>> * The executable (and DLL) are moved to a "bin" directory in an installed
>> Python.
>> * distutils etc will change to install all "scripts" (or executables
>> generated from scripts) int
On 21 March 2012 22:43, Mark Hammond wrote:
> On 22/03/2012 1:22 AM, Lindberg, Van wrote:
>>
>> Mark, MAL, Martin, Tarek,
>>
>> Could you comment on this?
>
>
> Eric is correct - tools will be broken by this change. However, people seem
> willing to push forward on this and accept such breakage a
On 22 March 2012 14:17, VanL wrote:
> As this has been brought up a couple times in this subthread, I figured that
> I would lay out the rationale here.
I'm repeating myself here after I promised not to. My apologies, but I
don't think this posting captures the debate completely. One reason I
sug
On 23 March 2012 03:20, Brian Curtin wrote:
>> Breakage of existing tools: Mark Hammond, Paul Moore, and Tim Golden have
>> all expressed that they have existing tools that would break and would need
>> to be adjusted to match the new location of the python.exe, because t
On 22 March 2012 23:15, VanL wrote:
> Another use case was just pointed out to me: making things consistent with
> buildout. Given a similar use
> case (create repeatable cross platform environments), they create and use a
> 'bin' directory for executable files.
Another problem case: cx_Freeze.
On 23 March 2012 20:40, Glyph wrote:
> I am increasingly thinking that the first order of business here should be
> to expose the platform-specific mechanisms directly, then try to come up
> with a unifying abstraction in the time module later.
+1.
Paul
__
On 25 March 2012 19:51, Serhiy Storchaka wrote:
> Anyone can test.
>
> $ ./python -m timeit -s 'enc = "latin1"; import codecs; d =
> codecs.getdecoder(enc); x = ("\u0020" * 10).encode(enc)' 'd(x)'
> 1 loops, best of 3: 59.4 usec per loop
> $ ./python -m timeit -s 'enc = "latin1"; import co
On 27 March 2012 01:23, Scott Dial wrote:
> If you want to define new clocks, then I wish you would use the same
> definitions that C++0x is using. That is:
>
> system_clock = wall clock time
> monotonic_clock = always goes forward but can be adjusted
> steady_clock = always goes forward and ca
(Sorry, should have sent to the list).
On 4 April 2012 01:04, Greg Ewing wrote:
> Cameron Simpson wrote:
>>
>> People have been saying "hires" throughout the
>> threads I think, but I for one would be slightly happier with "highres".
>
>
> hirez?
What's wrong with high_resolution?
Paul
_
On 6 April 2012 02:50, Cameron Simpson wrote:
(Quoted from the Linux manpage)
> All implementations support the system-wide real-time clock, which
> is identified by CLOCK_REALTIME. Its time represents seconds and
> nanoseconds since the Epoch. When its time is changed, timers for
> a
On 6 April 2012 11:12, Steven D'Aprano wrote:
> Glyph Lefkowitz wrote:
>
>> On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote:
>>
>
> 2. Those who think that "monotonic clock" means a clock that never jumps,
>>> and that runs at a rate approximating the rate of real time. This is a
>>> very
On 7 April 2012 09:12, Stephen J. Turnbull wrote:
>
> I don't think that's a reason that should be considered. There just
> doesn't seem to be a single best clock, nor do clocks of similar
> character seem to be easy to find across platforms. So the reasons
> I'd like to see are of the form "we
On 14 April 2012 06:41, Stephen J. Turnbull wrote:
> A clock can be accurate in measuring
> duration even though it is not accurate in measuring the point in
> time. [It's hard to see how the opposite could be true.]
Pedantic point: A clock that is stepped (say, by NTP) is precisely one
that is
On 14 April 2012 21:03, Brett Cannon wrote:
> So what I propose to do is stop having import have any kind of implicit
> machinery. This means sys.meta_path gets a path finder that does the heavy
> lifting for import and sys.path_hooks gets a hook which provides a default
> finder.
+1 to your prop
On 15 April 2012 18:13, Raymond Hettinger wrote:
> We should publish some advice on creating content managers.
>
> Context managers are a general purpose tool but have a primary
> use case of creating and releasing resources. This creates an
> expectation that that is what the context managers ar
On 16 April 2012 17:10, Nam Nguyen wrote:
> PEP 8 suggests no extra spaces after and before square brackets, and
> colons. So code like this is appropriate:
>
> a_list[1:3]
>
> But I find it less readable in the case of:
>
> a_list[pos + 1:-1]
>
> The colon is seemingly lost in the right.
>
> Woul
On 7 May 2012 21:55, "Martin v. Löwis" wrote:
>> This sounds to me like a level of complexity unwarranted by the severity
>> of the problem, especially when considering the additional burden it
>> imposes on alternative Python implementations.
>
>
> OTOH, it *significantly* reduces the burden on P
On 8 May 2012 17:14, Carl Meyer wrote:
> I don't think anyone has proposed making symlinks the default on Windows. At
> this point the two options on Windows would be to use the --symlink option
> explicitly, or else to need to run "pyvenv --upgrade" on your envs if you
> upgrade the underlying Py
On 21 May 2012 08:35, Hynek Schlawack wrote:
> Also -1 on docs3, that would suggest that it’s still something special
> and 2 (= docs) is the real deal.
Good point.
Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
On 29 May 2012 17:55, Victor Stinner wrote:
> 2012/5/29 Nadeem Vawda :
>> Since this changeset, building on Windows seems to be broken (see
>> http://python.org/dev/buildbot/all/builders/x86%20XP-5%203.x/builds/450
>> for example).
>
> The following changesets should fix the two errors, but not wa
On 14 June 2012 15:50, Alexandre Zani wrote:
> Comparing with strings is error prone. If I do param.is_varargs
> (adding an s at the end of the attribute name) I will see an attribute
> error and know what is going on. If I do the same mistake with the
> kind attribute param.kind == "varargs", the
On 15 June 2012 12:32, Nick Coghlan wrote:
> Now, what a function *could* do is set __signature__ to a Signature
> subclass that provided an additional "validate()" method, or provided
> arbitrary additional information about supported features. That's a
> perfectly reasonable option.
It might be
On 19 June 2012 22:46, Éric Araujo wrote:
[...]
> This leaves (d), after long reflection, as my preferred choice, even though
> I disliked the idea at first (and I fully expect Tarek to feel the same
> way).
I agree with Nick. It's regrettable, but this is probably the wisest
course of action. R
On 20 June 2012 10:12, Antoine Pitrou wrote:
> I think the whole idea that distutils should be frozen and improvements
> should only go in distutils2 has been misled. Had distutils been
> improved instead, many of those enhancements would already have been
> available in 3.2 (and others would soon
On 20 June 2012 11:34, Tarek Ziadé wrote:
> On 6/20/12 11:54 AM, Antoine Pitrou wrote:
>>
>> On Wed, 20 Jun 2012 09:51:03 + (UTC)
>> Vinay Sajip wrote:
>>>
>>> Antoine Pitrou pitrou.net> writes:
>>>
Deciding to remove packaging from 3.3 is another instance of the same
mistake, IMO
On 20 June 2012 13:53, Nick Coghlan wrote:
[...]
> 3.4 PEP: Simple binary package distribution format
> --
>
> bdist_simple has been discussed enough times, finally seeing a PEP
> for it would be nice :)
I had a PEP for th
On 20 June 2012 14:16, Alexis Métaireau wrote:
> On 20/06/2012 13:31, Tarek Ziadé wrote:
>>
>> packaging.metadata is the implementation of all metadata versions.
>> standalone too.
>>
>> packaging.pypi is the PyPI crawler, and has fairly advanced features. I
>> defer to Alexis to tell us
>> is it'
On 20 June 2012 14:47, Paul Moore wrote:
> On 20 June 2012 14:16, Alexis Métaireau wrote:
>> packaging.pypi is functionally working but IMO the API can (and probably
>> should) be improved (we really lack feedback to know that).
>
> I wasn't aware of this - I've
On 20 June 2012 17:07, Carl Meyer wrote:
> Hi Paul,
>
> On 06/20/2012 09:29 AM, Paul Moore wrote:
>> As a specific example, one thing I would like to do is to be able to
>> set up a packaging.pypi client object that lets me query and download
>> distributions. However
Can I take a step back and make a somewhat different point.
Developer requirements are very relevant, sure. But the most important
requirements are those of the end user. The person who simply wants to
*use* a distribution, couldn't care less how it was built, whether it
uses setuptools, or whatev
On 22 June 2012 06:05, Nick Coghlan wrote:
> distutils really only plays at the SRPM level - there is no defined OS
> neutral RPM equivalent. That's why I brought up the bdist_simple
> discussion earlier in the thread - if we can agree on a standard
> bdist_simple format, then we can more cleanly
On 22 June 2012 11:28, Dag Sverre Seljebotn wrote:
> And I'm saying that would encourage a culture that's very dangerous from a
> security perspective. Even if many uses binaries, it is important to
> encourage a culture where it is always trivial (well, as trivial as we can
> possibly make it, in
On 22 June 2012 13:39, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
> > On Fri, Jun 22, 2012 at 4:25 PM, Stephen J. Turnbull
> wrote:
> > > Paul Moore writes:
> > >
> > > > End users should not need packaging tools on their machines.
> &g
On 22 June 2012 13:09, Vinay Sajip wrote:
> Paul Moore gmail.com> writes:
>
>> Signed binaries may be a solution. My experience with signed binaries
>> has not been exactly positive, but it's an option. Presumably PyPI
>> would be the trusted authority? Would
On 27 June 2012 12:34, Antoine Pitrou wrote:
> On Wed, 27 Jun 2012 21:19:57 +1000
> Nick Coghlan wrote:
>> I thought the PEP actually covered it pretty well:
>> - if you don't want to worry about name conflicts for every module, pick
>> *one* short top level namespace for your group and use that
On 27 June 2012 13:20, Paul Moore wrote:
> I agree. I only skimmed the PEP, but even on a skimming, I got the
> impression that it was promoting the use of namespaces for ownership,
> in a Java-like way. The part Nick quoted is substantially more
> reasonable (assuming that'
On 28 June 2012 11:36, Benoît Bryon wrote:
>> Also, I don't see what's so important about using
>> your company's name as a top-level namespace. You don't need it for
>> conflict avoidance: you can just as well use distinctive project names.
>
> Using company's name as top-level namespace has been
On 13 September 2012 12:32, Tarek Ziadé wrote:
> Here's my proposal - actually it's Nick's proposal but I want to make sure
> we're on the same
> page wrt steps, and I think that addresses Antoine concerns
>
> 1. create a new package, called pkglib (or whatever), located at hg
> .python.org as a n
On 14 September 2012 17:30, Daniel Holth wrote:
> we strongly recommend it be named as README.* and be
> utf-8 encoded text.
I'd very strongly recommend that the encoding should be mandated. I'm
happy with UTF-8 (although I expect a lot of "accidental" latin-1
files, particularly from Windows use
On 14 September 2012 16:12, Vinay Sajip wrote:
> I have set up a BitBucket repo called distlib, at
>
> https://bitbucket.org/vinay.sajip/distlib/
>
> This has the following bits of distutils2 / packaging, updated to run on 2.x
> and
> 3.x with a single codebase, and including tests (though not do
On 16 September 2012 23:26, Vinay Sajip wrote:
> I think all that's needed (at the same level of abstraction) is a method
> write_installed_files(iterable_of_absolute_file_paths) which writes the file.
> This code is already in the distutils2.install_distinfo.install_distinfo.run()
> method. I'll
On 28 September 2012 19:19, Stefan Krah wrote:
> Brett Cannon wrote:
>> Georg Brandl wrote:
>> > * A C implementation of the "decimal" module, with up to 80x speedup
>> > for decimal-heavy applications
>>
>> Could you bump up the factor to 120x in the final announcement? Ther
On 29 September 2012 10:17, Stefan Krah wrote:
> Tim Delaney wrote:
>> If those numbers are similar in other benchmarks, would it be accurate and/or
>> reasonable to include a statement along the lines of:
>>
>> "comparable to float performance - usually no more than 3x for calculations
>> within
On 29 September 2012 14:24, Eli Bendersky wrote:
> On Sat, Sep 29, 2012 at 5:18 AM, Georg Brandl wrote:
>> On behalf of the Python development team, I'm delighted to announce the
>> Python 3.3.0 final release.
>>
>
> Yay :)
Agreed - this is a really nice release, thanks to all who put it togethe
On 3 October 2012 16:13, Larry Hastings wrote:
> On 10/03/2012 04:55 PM, Nick Coghlan wrote:
>
> Regardless of when the first alpha happens, I'll be promoting the hell
> out of it, begging for feedback on any of these changes that are
> available by then (which should be quite a few, given the pre
On 3 October 2012 17:34, R. David Murray wrote:
> There *were* bug reports during the alpha phase. A number of regressions
> were caught. Also, there were more alpha-phase bug reports than
> I remember getting for 3.2. I remember thinking, "wow, cool, we're
> actually getting regression bug rep
On 22 October 2012 21:35, Daniel Holth wrote:
> On Mon, Oct 22, 2012 at 4:26 PM, Daniel Holth wrote:
>> On Mon, Oct 22, 2012 at 4:20 PM, Antoine Pitrou wrote:
>>>
>>> Hello,
>>>
>>> The FAQ has this weird statement:
>>>
>>> “This specification does not have an opinion on how you should organize
On 26 October 2012 08:54, Ronald Oussoren wrote:
>>
>> It's nice and small. The encoder is just
>> base64.urlsafe_b64encode(digest).rstrip('=')
>
> But is the size difference really important? The wheel file itself is
> compressed, and the additional
> amount of space needed on installation shoul
On 27 October 2012 21:58, wrote:
>
> Zitat von Tim Delaney :
>
>
>> To be clear - I'm *not* suggesting Cython become part of the required
>> build
>> toolchain. But *if* the Cython-compiled extensions prove to be
>> significantly faster I'm thinking maybe it could become a semi-supported
>> optio
On 13 November 2012 10:26, M.-A. Lemburg wrote:
> I agree with Martin. If the point is to "to protect against cryptography
> that is not used", then not using the de-facto standard in signing
> open source distribution files, which today is PGP/GPG, misses that
> point :-)
>
I agree as well. For
On 14 November 2012 12:04, Daniel Holth wrote:
> That has been tried already (setuptools, distribute, distutils2). Instead,
> try bento (http://cournape.github.com/Bento/).
>
> Hilariously everyone I've showed it to is immediately put off by the
> indentation based syntax (who would use such a th
On 10 December 2012 16:35, Toshio Kuratomi wrote:
> I have no problems with Obsoletes, Conflicts, Requires, and Provides types
> of fields are marked informational. In fact, there are many cases where
> packages are overzealous in their use of Requires right now that cause
> distributions to patc
On 11 December 2012 15:39, Dirkjan Ochtman wrote:
>> Should the windows installer include the data package?
>> --
>>
>> It has been suggested that the Windows installer should include the data
>> package. This would mean that an explicit installa
On 12 December 2012 00:58, Nick Coghlan wrote:
> I'd prefer a more aggressive name for this like "tzdata_override". My
> rationale is that *nix users need to thoroughly aware that if they install
> this package, they will stop benefiting from the automatic tz database
> updates provided by their O
On 12 December 2012 16:11, Brian Curtin wrote:
> I don't think it's all that bad to include a small script on Windows
> which runs every few days to check PyPI, then present an option to
> update the info. This is what Java itself is doing anyway.
What would that do in an environment without inte
On 3 February 2013 11:27, Antoine Pitrou wrote:
>> I don't expect anything I want to do to be particularly controversial,
>> but I think it's worth trying to get it right (even if it delays wheel
>> support in pip for a few more weeks).
>
> Will wheel be implemented in distutils?
There are no pla
On 3 February 2013 14:41, Daniel Holth wrote:
> The neat thing about wheel is that you can install them without having the
> software used to build them. So we might try to provide a very simple wheel
> installer script with Python that did not even depend on DistUtils. You
> would be able to inst
On Fri, 10 Dec 2004 10:06:59 +, Armin Rigo <[EMAIL PROTECTED]> wrote:
> For people like myself, Linux programmers not developing on Windows every day,
> there is precious little information available about how to compile our
> extension modules for the new Windows distribution. I was actually
On Fri, 10 Dec 2004 17:19:21 +, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Another note: can you report on whether building libpython24.a can be skipped
> for mingw?
A first attempt seems to almost work. There is a problem with
structures, however - I get an error about unresolved references to
_
On Fri, 10 Dec 2004 20:40:10 +, Paul Moore <[EMAIL PROTECTED]> wrote:
> On Fri, 10 Dec 2004 17:19:21 +, Armin Rigo <[EMAIL PROTECTED]> wrote:
> > Another note: can you report on whether building libpython24.a can be
> > skipped
> > for mingw?
>
&g
On Sat, 11 Dec 2004 19:17:28 -0800, Brett C. <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
>
> > Anyway, all comments are appreciated (even a simple "Sounds good to me").
> >
>
> Sounds good to me. =)
And me :-)
+1
Paul.
___
Python-Dev mailing lis
On Sat, 11 Dec 2004 19:57:55 +0100, Christian Tismer
<[EMAIL PROTECTED]> wrote:
> Armin Rigo wrote:
> > Hum, this is getting into a Linux-vs-Windows argument. I don't want to
> > invest
> > time and money on Windows tools just to compile my extension module for
> > Windows users...
First of all
On Sun, 12 Dec 2004 23:19:55 +, A.B., Khalid <[EMAIL PROTECTED]> wrote:
> [2] Can someone who has the official Python 2.4 download the sample
> extension [**] created using the pyMinGW patched & MinGW compiled Python 2.4
> and SWIG? And see if it works?
> Sources are in the zip file whose
On Mon, 13 Dec 2004 23:17:51 +0100, Martin v. Löwis <[EMAIL PROTECTED]> wrote:
> I forgot the details of your analysis, but I think you are right.
> However, I would feel more comfortable if only a single CRT was used
> from an extension module.
Agreed. But to some extent I'm equally uncomfortable
On Tue, 14 Dec 2004 01:05:09 -0200, Rodrigo Dias Arruda Senra
<[EMAIL PROTECTED]> wrote:
> But, but to the joke: I believe Python must strive to run at least as fast as
> the crowd --
> Java, Perl, Ruby, Lua, Boo, etc
>
> Maybe we could visit the language shootout sites, translate Python snipets
On Tue, 14 Dec 2004 23:48:41 +0100, Martin v. Löwis <[EMAIL PROTECTED]> wrote:
> I understand that one still needs to build libpython24.a in order to
> use this process. As I have said, I'd happily ship that file with the
> 2.4.1 MSI, unless the release manager tells me that this would an
> unaccep
On Mon, 13 Dec 2004 16:43:18 +, A.B., Khalid <[EMAIL PROTECTED]> wrote:
> So what see ye? :) Does it look good?
Looks good to me. The one remaining link to msvcrt, abort, is likely
to be due to the startup code using it, and your code not referencing
that symbol, so that it doesn't force linki
1601 - 1700 of 1862 matches
Mail list logo
