On 5 September 2016 at 21:40, eryk sun wrote:
> On Mon, Sep 5, 2016 at 7:54 PM, Steve Dower wrote:
>> On 05Sep2016 1234, eryk sun wrote:
>>> It would probably be simpler to use UTF-16 in the main pipeline and
>>> implement Martin's suggestion to mix in a UTF-8 buffer. The UTF-16
>>> buffer could
On Mon, Sep 5, 2016 at 3:30 AM, Random832 wrote:
> On Sun, Sep 4, 2016, at 16:42, Koos Zevenhoven wrote:
>> On Sun, Sep 4, 2016 at 6:38 PM, Nick Coghlan wrote:
>> >
>> > There are two self-consistent sets of names:
>> >
>>
>> Let me add a few. I wonder if this is really used so much that
>> bytes
On Tue, Sep 6, 2016, at 06:34, Martin Panter wrote:
> Yes, that was basically it. Though I had only thought as far as simple
> encodings like ASCII, where one byte corresponds to one character. I
> wonder if you really need UTF-8 support. Are the encoding values
> currently encountered for Windows
On Mon, Sep 5, 2016 at 6:06 AM, Nick Coghlan wrote:
> On 5 September 2016 at 06:42, Koos Zevenhoven wrote:
>> On Sun, Sep 4, 2016 at 6:38 PM, Nick Coghlan wrote:
>>>
>>> There are two self-consistent sets of names:
>>>
>>
>> Let me add a few. I wonder if this is really used so much that
>> bytes
On 05/09/16 23:16, Greg Ewing wrote:
Mark Shannon wrote:
Unless of course, others may have a different idea of what the "type
of a variable" means.
To me, it means it means that for all assignments `var = expr`
the type of `expr` must be a subtype of the variable,
and for all uses of var, the
On 05/09/16 18:40, Guido van Rossum wrote:
On Mon, Sep 5, 2016 at 8:26 AM, Mark Shannon wrote:
PEP 526 states that "This PEP aims at adding syntax to Python for annotating
the types of variables" and Guido seems quite insistent that the
declarations are for the types of variables.
However, I
On 6 September 2016 at 17:25, Mark Shannon wrote:
> The issue is not whether the checker can tell that the type of the
> *expression* is int, but whether it is forced to use the type of the
> *variable*. The current wording of PEP 526 strongly implies the latter.
>
Mark,
Could you please point t
On 05/09/16 14:46, Nick Coghlan wrote:
> That's not what the PEP proposes for uninitialised variables though:
> it proposes processing them *before* a series of assignment
> statements, which *only makes sense* if you plan to use them to
> constrain those assignments in some way.
>
> If you wanted
On 6 September 2016 at 14:04, Guido van Rossum wrote:
> I'm sorry, but we're not going to invent new syntax this late in the
> game. The syntax proposed by the PEP has been on my mind ever since
> PEP 484 with very minor variations; I first proposed it seriously on
> python-ideas over a month ago,
On 6 September 2016 at 02:51, Ian Foote wrote:
> On 05/09/16 14:46, Nick Coghlan wrote:
>> That's not what the PEP proposes for uninitialised variables though:
>> it proposes processing them *before* a series of assignment
>> statements, which *only makes sense* if you plan to use them to
>> const
On Tue, Sep 6, 2016 at 9:00 AM, Nick Coghlan wrote:
> On 6 September 2016 at 14:04, Guido van Rossum wrote:
>> I'm sorry, but we're not going to invent new syntax this late in the
>> game. The syntax proposed by the PEP has been on my mind ever since
>> PEP 484 with very minor variations; I first
Sir
I learn the basics of python from online and I am pretty much confident
with my basics and I want to show them to the outside world by publishing them
as packages in python. There were set of instructions for that process but I
could not figure out the exact process so please help m
On 7 September 2016 at 01:33, Ivan Levkivskyi wrote:
> On 6 September 2016 at 17:25, Mark Shannon wrote:
>>
>> The issue is not whether the checker can tell that the type of the
>> *expression* is int, but whether it is forced to use the type of the
>> *variable*. The current wording of PEP 526 s
Wrong mailing list. This is for the discussion of development *of* Python,
not *in* Python. You probably want:
https://mail.python.org/mailman/listinfo/python-list
Regardless, this page should answer your questions:
https://packaging.python.org/distributing/
On Tue, Sep 6, 2016 at 11:31 AM, RA
Hello Ramu,
This is the wrong place to ask for help with your question, this is for
development of the Python interpreter.
I suggest you subscribe to the Python-List mailing list.
For help with publishing packages, see
https://wiki.python.org/moin/CheeseShopTutorial
On Tue, Sep 06, 2016 at
On 6 September 2016 at 18:35, Nick Coghlan wrote:
> On 7 September 2016 at 01:33, Ivan Levkivskyi
> wrote:
> > On 6 September 2016 at 17:25, Mark Shannon wrote:
> >>
> >> The issue is not whether the checker can tell that the type of the
> >> *expression* is int, but whether it is forced to use
Mark Shannon writes:
> The problem with using the term "variable" is that it is *not* vague.
> Variables in python have well defined scopes and lifetimes.
Sure, but *hints* are not well-defined by Python (except the syntax,
once PEP 526 is implemented). A *hint* is something that the
typechec
On Wed, Sep 7, 2016 at 4:11 AM, Stephen J. Turnbull
wrote:
> Finally, the notion of annotating expressions is incoherent:
>
> # Annotating (sub)expressions: the more the merrier!
> (x) : bool = (((y): int + (z): float) / (w): complex): quarternion
> # Ooh, an expression with no past an
This is all about current (3.6) trunk.
In Objects/weakrefobject.c, we have the function
PyObject_ClearWeakRefs(). This is called when a generic object that
supports weakrefs is destroyed; this is the code that calls the
callbacks. Here's a little paragraph of code from the center:
for
Hi Ronald,
The feature freeze for 3.6 is closing in a few days; 3.6b1 will go out
this weekend. Did you overcome the issue, or does your PEP need to be
postponed until 3.7?
--Guido
On Sun, Jul 24, 2016 at 9:58 PM, Ronald Oussoren wrote:
>
> On 24 Jul 2016, at 13:06, Ronald Oussoren wrote:
>
>
I'm not anticipating much discussion on this, but wanted to present a
summary of my notes from the project I proposed last year and have
since tabled.
http://ericsnowcurrently.blogspot.com/2016/09/solving-mutli-core-python.html
-eric
___
Python-Dev mail
Hi,
I've updated PEP 525 with a new section about asyncio changes.
Essentially, asyncio event loop will get a new "shutdown_asyncgens"
method that allows to close the loop and all associated AGs with it
reliably.
Only the updated section is pasted below:
asyncio
---
The asyncio event
This code appears to have been added to fix
https://bugs.python.org/issue3100 - A crash involving a weakref subclass.
-gps
On Tue, Sep 6, 2016 at 3:51 PM Larry Hastings wrote:
>
> This is all about current (3.6) trunk.
>
> In Objects/weakrefobject.c, we have the function
> PyObject_ClearWeakRef
Thanks Yury!
I am hereby accepting PEP 525 provisionally. The acceptance is so that
you can go ahead and merge this into 3.6 before the feature freeze
this weekend. The provisional status is because this is a big project
and it's likely that we'll need to tweak some small aspect of the API
once th
On Tue, Sep 6, 2016 at 8:25 AM, Mark Shannon wrote:
> The "smartness" of checkers is not the problem (for this example, at least)
> the problem is that checkers must conform to the rules laid down in PEP 484
> and (in whatever form it finally takes) PEP 526.
> It sounds like mypy doesn't conform t
The implementation of '_' in numeric literals is here:
http://bugs.python.org/issue26331
And to add '_' in int.__format__ is here:
http://bugs.python.org/issue27080
But I don't want to add support in int.__format__ unless numeric literal
support is added.
So, Georg and Serhiy: is issue 26331
At the dev sprint today, we discussed PEP 515; several people are keen to see
it get into 3.6. If someone doesn't get to it before tomorrow, one of the
sprinters will try to do a final review and get it pushed.
--
Ned Deily
n...@python.org -- []
> On Sep 6, 2016, at 21:21, Eric V. Sm
27 matches
Mail list logo
