On 17.03.2016 15:02, Serhiy Storchaka wrote:
> On 17.03.16 15:14, M.-A. Lemburg wrote:
>> On 17.03.2016 01:29, Guido van Rossum wrote:
>>> Should we recommend that everyone use tokenize.detect_encoding()?
>>
>> I'd prefer a separate utility for this somewhere, since
>> tokenize.detect_encoding() is
On 17.03.16 15:14, M.-A. Lemburg wrote:
On 17.03.2016 01:29, Guido van Rossum wrote:
Should we recommend that everyone use tokenize.detect_encoding()?
I'd prefer a separate utility for this somewhere, since
tokenize.detect_encoding() is not available in Python 2.
I've attached an example impl
There's a more fundamental PEP 484 update that I'd like to add. The
discussion is in https://github.com/python/typing/issues/107.
Currently we don't have a way to talk about arguments and variables
whose type is itself a type or class. The only annotation you can use
for this is 'type' which says
Heh. I could add an example with a long list of parameters with long
names, but apart from showing by example what the motivation is it
wouldn't really add anything, and it's more to type. :-)
On Sat, Mar 19, 2016 at 6:43 PM, Andrew Barnert wrote:
> On Mar 19, 2016, at 18:18, Guido van Rossum wr
Here's another proposal for a change to PEP 484.
In https://github.com/python/typing/issues/72 there's a long
discussion ending with a reasonable argument to allow @overload in
(non-stub) modules after all.
This proposal does *not* sneak in a syntax for multi-dispatch -- the
@overload versions ar
On Mar 19, 2016, at 18:18, Guido van Rossum wrote:
>
> Second, https://github.com/python/typing/issues/186. This builds on
> the previous syntax but deals with the other annoyance of long
> argument lists, this time in case you *do* care about the types. The
> proposal is to allow writing the arg
On 3/16/2016 12:59 AM, Serhiy Storchaka wrote:
On 16.03.16 09:46, Glenn Linderman wrote:
On 3/16/2016 12:09 AM, Serhiy Storchaka wrote:
On 16.03.16 08:34, Glenn Linderman wrote:
From the PEP 263:
More precisely, the first or second line must match the regular
expression "coding[:=]\s*([
PEP 484 was already updated to support signatures as type comments in
Python 2.7. I'd like to add two more variations to this spec, both of
which have already come up through users.
First, https://github.com/python/typing/issues/188. This augments the
format of signature type comments to allow (..
Hi,
I have an API question for you.
I would like to add a new parameter the the showwarning() function of
the warnings module. Problem: it's not possible to do that without
breaking the backward compatibility (when an application replaces
warnings.showwarning(), the warnings allows and promotes t
On Mar 17, 2016, at 18:35, MRAB wrote:
>
>> On 2016-03-18 00:56, Michael Felt wrote:
>> Update:
>> Is this going to be impossible?
> From what I've been able to find out, the C89 standard limits bitfields to
> int, signed int and unsigned int, and the C99 standard added _Bool, although
> some c
On 3/19/2016 2:37 PM, Serhiy Storchaka wrote:
On 19.03.16 19:36, Glenn Linderman wrote:
On 3/19/2016 8:19 AM, Serhiy Storchaka wrote:
On 16.03.16 08:03, Serhiy Storchaka wrote:
I just tested with Emacs, and it looks that when specify different
codings on two different lines, the first coding wi
On 19.03.16 19:36, Glenn Linderman wrote:
On 3/19/2016 8:19 AM, Serhiy Storchaka wrote:
On 16.03.16 08:03, Serhiy Storchaka wrote:
I just tested with Emacs, and it looks that when specify different
codings on two different lines, the first coding wins, but when
specify different codings on the s
ACTIVITY SUMMARY (2016-03-11 - 2016-03-18)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open5459 ( +5)
closed 32885 (+43)
total 38344 (+48)
Open issues wit
On 17.03.2016 18:53, Serhiy Storchaka wrote:
> On 17.03.16 19:23, M.-A. Lemburg wrote:
>> On 17.03.2016 15:02, Serhiy Storchaka wrote:
>>> On 17.03.16 15:14, M.-A. Lemburg wrote:
On 17.03.2016 01:29, Guido van Rossum wrote:
> Should we recommend that everyone use tokenize.detect_encoding()
All that sounds fine!
On Sat, Mar 19, 2016 at 11:28 AM, Stefan Krah wrote:
> Guido van Rossum python.org> writes:
>> So should the preprocessing step just be s.replace('_', ''), or should
>> it reject underscores that don't follow the rules from the PEP
>> (perhaps augmented so they follow the s
Guido van Rossum python.org> writes:
> So should the preprocessing step just be s.replace('_', ''), or should
> it reject underscores that don't follow the rules from the PEP
> (perhaps augmented so they follow the spirit of the PEP and the letter
> of the IBM spec)?
>
> Honestly I think it's als
Glenn Linderman writes:
> On 3/19/2016 8:19 AM, Serhiy Storchaka wrote:
> > Therefore current CPython behavior can be correct, and the regular
> > expression in PEP 263 should be changed to use greedy repetition.
>
> Just because emacs works that way (and even though I'm an emacs user),
>
So should the preprocessing step just be s.replace('_', ''), or should
it reject underscores that don't follow the rules from the PEP
(perhaps augmented so they follow the spirit of the PEP and the letter
of the IBM spec)?
Honestly I think it's also fine if specifying this exactly is left out
of t
On 3/19/2016 8:19 AM, Serhiy Storchaka wrote:
On 16.03.16 08:03, Serhiy Storchaka wrote:
On 15.03.16 22:30, Guido van Rossum wrote:
I came across a file that had two different coding cookies -- one on
the first line and one on the second. CPython uses the first, but mypy
happens to use the seco
Guido van Rossum python.org> writes:
> I don't care too much either way, but I think passing underscores to the
constructor shouldn't be affected by the context -- the underscores are just
removed before parsing the number. But if it's too complicated to implement
I'm fine with punting.
Just rem
I don't care too much either way, but I think passing underscores to the
constructor shouldn't be affected by the context -- the underscores are
just removed before parsing the number. But if it's too complicated to
implement I'm fine with punting.
--Guido (mobile)
On Mar 19, 2016 6:24 AM, "Nick C
On 17.03.2016 01:29, Guido van Rossum wrote:
> I've updated the PEP. Please review. I decided not to update the
> Unicode howto (the thing is too obscure). Serhiy, you're probably in a
> better position to fix the code looking for cookies to pick the first
> one if there are two on the same line (o
On 16.03.16 08:03, Serhiy Storchaka wrote:
On 15.03.16 22:30, Guido van Rossum wrote:
I came across a file that had two different coding cookies -- one on
the first line and one on the second. CPython uses the first, but mypy
happens to use the second. I couldn't find anything in the spec or
doc
On 17.03.2016 15:55, Guido van Rossum wrote:
> On Thu, Mar 17, 2016 at 5:04 AM, Serhiy Storchaka wrote:
>>> Should we recommend that everyone use tokenize.detect_encoding()?
>>
>> Likely. However the interface of tokenize.detect_encoding() is not very
>> simple.
>
> I just found that out yesterda
On 17.03.16 21:11, Guido van Rossum wrote:
I tried this and it was too painful, so now I've just
changed the regex that mypy uses to use non-eager matching
(https://github.com/python/mypy/commit/b291998a46d580df412ed28af1ba1658446b9fe5).
\s* matches newlines.
{0,1}? is the same as ??.
__
Update:
Is this going to be impossible?
test_short fails om AIX when using xlC in any case. How terrible is this?
==
FAIL: test_shorts (ctypes.test.test_bitfields.C_Test)
-
Hi,
I am now looking for a Google Summer of Code (GSoC) student to help me
of my FAT Python project, a new static optimizer for CPython 3.6 using
specialization with guards.
The FAT Python project is already fully functional, the code is
written and tested. I need help to implement new efficient
a) hope this is not something you expect to be on -list, if so - my
apologies!
Getting this message (here using c99 as compiler name, but same issue
with xlc as compiler name)
c99 -qarch=pwr4 -qbitfields=signed -DNDEBUG -O -I. -IInclude -I./Include
-I/data/prj/aixtools/python/python-2.7.11.2/I
On 3/16/2016 3:14 AM, Serhiy Storchaka wrote:
On 16.03.16 02:28, Guido van Rossum wrote:
I agree that the spirit of the PEP is to stop at the first coding
cookie found. Would it be okay if I updated the PEP to clarify this?
I'll definitely also update the docs.
Could you please also update the
On 19 March 2016 at 16:44, Georg Brandl wrote:
> On the other hand, assuming decimal literals are introduced at some
> point, they would almost definitely need to support underscores.
> Of course, the decision whether to modify the Decimal constructor
> can be postponed until that time.
The idea
On Thu, Mar 17, 2016 at 5:04 AM, Serhiy Storchaka wrote:
>> Should we recommend that everyone use tokenize.detect_encoding()?
>
> Likely. However the interface of tokenize.detect_encoding() is not very
> simple.
I just found that out yesterday. You have to give it a readline()
function, which is
Hello everyone,
I am Wasim Thabraze, a Computer Science Undergraduate. I have thoroughly
gone through the Core-Python GSoC ideas page and have narrowed down my
choices to the project 'Improving Roundup GitHub integration'.
I have experience in building stuff that are connected to GitHub. Openfloc
On 2016-03-18 00:56, Michael Felt wrote:
Update:
Is this going to be impossible?
From what I've been able to find out, the C89 standard limits bitfields
to int, signed int and unsigned int, and the C99 standard added _Bool,
although some compilers allow other integer types too. It looks like
On Thu, 17 Mar 2016 at 07:56 Guido van Rossum wrote:
> On Thu, Mar 17, 2016 at 5:04 AM, Serhiy Storchaka
> wrote:
> >> Should we recommend that everyone use tokenize.detect_encoding()?
> >
> > Likely. However the interface of tokenize.detect_encoding() is not very
> > simple.
>
> I just found th
On 17.03.16 21:11, Guido van Rossum wrote:
This will raise SyntaxError if the encoding is unknown. That needs to
be caught in mypy's case and then it needs to get the line number from
the exception.
Good point. "lineno" and "offset" attributes of SyntaxError is set to
None by tokenize.detect_e
Where did this PEP leave off? Anything blocking its acceptance?
On Sat, 13 Feb 2016 at 00:49 Georg Brandl wrote:
> Hi all,
>
> after talking to Guido and Serhiy we present the next revision
> of this PEP. It is a compromise that we are all happy with,
> and a relatively restricted rule that mak
On 3/16/2016 5:29 PM, Guido van Rossum wrote:
I've updated the PEP. Please review. I decided not to update the
Unicode howto (the thing is too obscure). Serhiy, you're probably in a
better position to fix the code looking for cookies to pick the first
one if there are two on the same line (or do
I've updated the PEP. Please review. I decided not to update the
Unicode howto (the thing is too obscure). Serhiy, you're probably in a
better position to fix the code looking for cookies to pick the first
one if there are two on the same line (or do whatever you think should
be done there).
Shoul
Guido van Rossum writes:
> > Should we recommend that everyone use tokenize.detect_encoding()?
+1
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/optio
On 17.03.16 02:29, Guido van Rossum wrote:
I've updated the PEP. Please review. I decided not to update the
Unicode howto (the thing is too obscure). Serhiy, you're probably in a
better position to fix the code looking for cookies to pick the first
one if there are two on the same line (or do wha
On 17.03.16 19:23, M.-A. Lemburg wrote:
On 17.03.2016 15:02, Serhiy Storchaka wrote:
On 17.03.16 15:14, M.-A. Lemburg wrote:
On 17.03.2016 01:29, Guido van Rossum wrote:
Should we recommend that everyone use tokenize.detect_encoding()?
I'd prefer a separate utility for this somewhere, since
I'll update the text so that the format() gets promoted from optional
to specified.
There was one point of discussion in the tracker issue that should be
resolved before acceptance: the Decimal constructor is listed as
getting updated to allow underscores, but its syntax is specified
in the Decima
42 matches
Mail list logo
