To facilitate review of the PEP 405 reference implementation, I want to update
my sandbox repository on hg.python.org with the relevant changes, so I can
create a patch for Rietveld.
I've added some files with CRLF line endings:
Lib/venv/scripts/nt/Activate.ps1
Lib/venv/scripts/nt/Dectivate.ps1
L
On 2 May 2012, at 18:06, Ezio Melotti wrote:
> On 02/05/2012 19.33, Michael Foord wrote:
>> On 2 May 2012, at 16:55, Terry Reedy wrote:
>>> I would send the above to webmas...@python.org (should be at the bottom of
>>> pages). We develop CPython but do not directly manage the website.
>> Not tru
On Thu, May 3, 2012 at 10:50 PM, Vinay Sajip wrote:
> Although these are text files, the CRLF line endings are needed because
> otherwise, the files won't be presented correctly on Windows, e.g. in Notepad.
Not all Windows editors choke on \n line endings; when I'm on Windows
and run into one, I
Chris Angelico gmail.com> writes:
> Not all Windows editors choke on \n line endings; when I'm on Windows
> and run into one, I open it in Wordpad (or, if I have one, a dedicated
> programming editor like SciTE or the Open Watcom editor). AFAIK only
> Notepad (of standard Windows utilities) has t
On Fri, May 4, 2012 at 1:28 AM, Vinay Sajip wrote:
> It's only really an issue for new / inexperienced users, I agree. Since these
> files are installed only on Windows systems, there's no reason for them not to
> have the native line endings.
Then sure, doesn't make a lot of difference that it's
On 5/3/2012 7:16 AM, victor.stinner wrote:
http://hg.python.org/cpython/rev/f1db931b93d3
changeset: 76730:f1db931b93d3
user:Victor Stinner
date:Thu May 03 13:10:40 2012 +0200
summary:
Issue #14687: str%tuple now uses an optimistic "unicode writer" instead of an
accumulator.
Zitat von Chris Angelico :
On Thu, May 3, 2012 at 10:50 PM, Vinay Sajip wrote:
Although these are text files, the CRLF line endings are needed because
otherwise, the files won't be presented correctly on Windows, e.g.
in Notepad.
Not all Windows editors choke on \n line endings; when I'm
>> http://hg.python.org/cpython/rev/f1db931b93d3
>> changeset: 76730:f1db931b93d3
>> user: Victor Stinner
>> date: Thu May 03 13:10:40 2012 +0200
>> summary:
>> Issue #14687: str%tuple now uses an optimistic "unicode writer" instead
>> of an
>> accumulator. Directly write characte
2012/5/3 victor.stinner :
> Py_LOCAL_INLINE(void)
Do these have to be marked inline?
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
>> Py_LOCAL_INLINE(void)
>
> Do these have to be marked inline?
Functions used in loops, yes: the inline keyword *does* impact
performances (5% slower). I removed the keyword for the other
unicode_writer methods.
Victor
___
Python-Dev mailing list
Pyth
Hi,
Different people are working on improving performances of Unicode
strings in Python 3.3. This Python version is very different from
Python 3.2 because of the PEP 393, and it is still unclear to me what
is the best way to create a new Unicode string.
There are different approachs:
* Use the
On 5/3/2012 2:00 PM, mar...@v.loewis.de wrote:
I think that .bat files strictly *have* to have CRLF line endings.
Nope. Both .bat and .cmd work fine with LF only in Win7 (and IIRC, in
XP as well, but I just tested Win7)
___
Python-Dev mailing list
P
> To me, "adjusted" and "is_adjusted" both imply that an adjustment
> has already been made; "adjustable" only implies that it is possible.
The documentation is:
"True if the clock can be adjusted (e.g. by a NTP daemon), False otherwise."
I prefer "adjustable", because no OS tell us if the clock
On 04May2012 01:47, Victor Stinner wrote:
| I prefer "adjustable", because no OS tell us if the clock has an
| ajustement or not... except Windows: see GetSystemTimeAdjustment().
|
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724394%28v=vs.85%29.aspx
|
| I propose to rename is_adjus
> I'm -1 on that. To my mind "adjustable" suggests that the caller can
> adjust the clock, while "adjusted" suggests that the clock may be adjusted
> by a mechanism outside the caller's hands. That latter is the meaning
> in the context of the PEP.
Anyway, the implementation and/or the documentati
On Fri, May 4, 2012 at 7:00 AM, wrote:
> In any case, having CRLF for these files sounds good to me.
Right. While Windows has been getting much better at coping with LF
only line endings over the years, being able to explicitly flag files
for CRLF endings is the entire reason we held out for the
On Fri, May 4, 2012 at 10:12 AM, Cameron Simpson wrote:
> On 04May2012 01:47, Victor Stinner wrote:
> | I prefer "adjustable", because no OS tell us if the clock has an
> | ajustement or not... except Windows: see GetSystemTimeAdjustment().
> |
> http://msdn.microsoft.com/en-us/library/windows/d
Various notes:
* PyUnicode_READ() is slower than reading a Py_UNICODE array.
* Some decoders unroll the main loop to process 4 or 8 bytes (32 or
64 bits CPU) at each step.
I am interested if you know other tricks to optimize Unicode strings
in Python, or if you are interested to work on this to
2012/5/3 larry.hastings :
> diff --git a/Modules/posixmodule.c b/Modules/posixmodule.c
> --- a/Modules/posixmodule.c
> +++ b/Modules/posixmodule.c
> @@ -3572,28 +3572,194 @@
> #endif /* HAVE_UNAME */
>
>
> +static int
> +split_py_long_to_s_and_ns(PyObject *py_long, time_t *s, long *ns)
> +{
> +
On Thu, May 3, 2012 at 12:46 AM, Antoine Pitrou wrote:
> Daily code coverage builds would be nice, but that's probably beyond
> what the current infrastructure can offer. It would be nice if someone
> wants to investigate that.
Code coverage buildbots would indeed be good. I could give a try on
t
On 05/03/2012 10:07 PM, Benjamin Peterson wrote:
+if (times&& ns) {
+PyErr_Format(PyExc_RuntimeError,
Why not a ValueError or TypeError?
Well it's certainly not a TypeError. The 3.2 documentation defines
TypeError as:
Raised when an operation or function is applied to an o
On Fri, May 4, 2012 at 4:04 PM, Larry Hastings wrote:
> Finally, I appreciate the feedback, but... why post it to python-dev? You
> could have sent me private email, or posted to the issue (#14127), the
> latter of which would have enabled using rich chocolaty Rietveld. I've seen
> a bunch of co
22 matches
Mail list logo
