On Fri, Jun 21, 2013 at 11:06 AM, Nick Coghlan wrote:
> On 21 June 2013 01:04, Thomas Wouters wrote:
>> If the .py file is going to be wrong or incomplete, why would we want to
>> keep it -- or use it as fallback -- at all? If we're dead set on having a
>> .py file instead of requiring it to be p
2013/6/21 Nick Coghlan :
> Because practicality beats purity. This "wrong" Python code has been
> good enough for all Python version up until 3.4, it makes sense to
> keep it as a fallback instead of throwing it away.
How do you plan to handle the following case in Python?
"Looking in more detail
On 05/21/2013 10:36 AM, Serhiy Storchaka wrote:
21.05.13 10:17, Hrvoje Niksic написав(ла):
On 05/20/2013 05:15 PM, Ethan Furman wrote:
1) Do nothing and be happy I use 'raise ... from None' in my own
libraries
2) Change the wording of 'During handling of the above exception,
another exceptio
On 21 June 2013 17:25, Victor Stinner wrote:
> 2013/6/21 Nick Coghlan :
>> Because practicality beats purity. This "wrong" Python code has been
>> good enough for all Python version up until 3.4, it makes sense to
>> keep it as a fallback instead of throwing it away.
>
> How do you plan to handle
Le Fri, 21 Jun 2013 21:39:10 +1000,
Nick Coghlan a écrit :
> On 21 June 2013 17:25, Victor Stinner
> wrote:
> > 2013/6/21 Nick Coghlan :
> >> Because practicality beats purity. This "wrong" Python code has
> >> been good enough for all Python version up until 3.4, it makes
> >> sense to keep it
Am 21.06.2013 13:45, schrieb Antoine Pitrou:
> For me, PEP 399 should not be considered a requirement but a guideline.
> stat.py is algorithmically trivial and I don't think it saves much work
> for authors of third-party Python implementations.
The module's content is rather boring. It's just a b
On 6/21/2013 7:39 AM, Nick Coghlan wrote:
> On 21 June 2013 17:25, Victor Stinner wrote:
>> 2013/6/21 Nick Coghlan :
>>> Because practicality beats purity. This "wrong" Python code has been
>>> good enough for all Python version up until 3.4, it makes sense to
>>> keep it as a fallback instead of
Hi python devs :
As a part of exploring an idea, I am trying to add a new method to the
python socket object. Here's what I have been trying to do (the patch may
be whitespace damaged so please bear with me) :
Index: Python-2.7/Modules/socketmodule.c
=
Technically this list isn't the right place, but you probably are
bitten by the duplication of functionality in Lib/socket.py. There's a
list of methods at the top of that file, _socketmethods.
But you really shouldn't be asking here -- this list is for changes to
Python, not using or hacking it.
Hi Ani,
just a simple question:
Are you sure, that you imported the modified socket module and not the original
module from the distribution?
HTH,
Gerald
Am 21.06.2013 um 07:18 schrieb Ani Sinha :
> Hi python devs :
>
> As a part of exploring an idea, I am trying to add a new method to the
On 21 June 2013 21:45, Antoine Pitrou wrote:
> Le Fri, 21 Jun 2013 21:39:10 +1000,
> Nick Coghlan a écrit :
>> What's not OK is for
>> the standard library to regress for other implementations just because
>> we added a C implementation for the benefit of CPython. That's exactly
>> the kind of th
Le Sat, 22 Jun 2013 01:29:40 +1000,
Nick Coghlan a écrit :
> On 21 June 2013 21:45, Antoine Pitrou wrote:
> > Le Fri, 21 Jun 2013 21:39:10 +1000,
> > Nick Coghlan a écrit :
> >> What's not OK is for
> >> the standard library to regress for other implementations just
> >> because we added a C imp
2013/6/21 Nick Coghlan :
> Basically, I want to hear from the Jython, PyPy and IronPython devs
> that they're OK with us deleting Lib/stat.py. Hearing other CPython
> devs say they're fine with it doesn't mean anything, since we're not
> the ones that will have to do additional work as a result.
ACTIVITY SUMMARY (2013-06-14 - 2013-06-21)
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:
open4057 (+15)
closed 25993 (+47)
total 30050 (+62)
Open issues wit
On 6/21/2013 7:45 AM, Antoine Pitrou wrote:
Le Fri, 21 Jun 2013 21:39:10 +1000,
Nick Coghlan a écrit :
I think it's OK to expose additional platform specific features in the
C version, and have them fail cleanly with the pure Python version
(rather than silently giving the wrong answer).
PE
Am 21.06.2013 17:47, schrieb Benjamin Peterson:
>
> Kill it. I would argue having incorrect constants makes the
> implementation incompatible with CPython anyway. This not that much
> work (as long as there are tests that the constants exist at least) to
> emulate.
>
My patch adds extensive test
Hello,
I've been appointed PEP 445 delegate by Nick and Guido. I would like to
know if there are still pending changes to the PEP. If not, I expect to
give it a review in the coming days or weeks, and then make a final
pronouncement (which will probably be positive anyway).
Regards
Antoine.
_
Hi Guido :
Thanks a lot. That helped.
I will try StackOverflow next time.
cheers,
ani
On Fri, Jun 21, 2013 at 8:07 AM, Guido van Rossum wrote:
> Technically this list isn't the right place, but you probably are
> bitten by the duplication of functionality in Lib/socket.py. There's a
> list
On 22/06/13 01:29, Nick Coghlan wrote:
Basically, I want to hear from the Jython, PyPy and IronPython devs
that they're OK with us deleting Lib/stat.py. Hearing other CPython
devs say they're fine with it doesn't mean anything, since we're not
the ones that will have to do additional work as a re
On 21/06/13 01:35, Benjamin Peterson wrote:
2013/6/20 Charles-François Natali :
2013/6/20 Thomas Wouters :
If the .py file is going to be wrong or incomplete, why would we want to
keep it -- or use it as fallback -- at all? If we're dead set on having a
.py file instead of requiring it to be pa
On Fri, Jun 21, 2013 at 9:29 AM, Nick Coghlan wrote:
> So why not just replace the *broken* parts of stat.py and keep the
> rest of it?
In some ways this sounds like yet another use case for what amounts to
properties on modules. The sketchy contants that are causing concern
could raise NotImple
Hi,
2013/6/21 Antoine Pitrou :
> I've been appointed PEP 445 delegate by Nick and Guido. I would like to
> know if there are still pending changes to the PEP.
Cool.
Hum, there is maybe something. In my pytracemalloc project, I added
another API to track usage of free lists:
PyAPI_FUNC(int) _PyF
On Fri, Jun 21, 2013 at 8:20 PM, Steven D'Aprano wrote:
> On 21/06/13 01:35, Benjamin Peterson wrote:
>
>> 2013/6/20 Charles-François Natali :
>>
>>> 2013/6/20 Thomas Wouters :
>>>
If the .py file is going to be wrong or incomplete, why would we want to
keep it -- or use it as fallback -
On 21Jun2013 21:39, Nick Coghlan wrote:
| On 21 June 2013 17:25, Victor Stinner wrote:
| > How do you plan to handle the following case in Python?
| >
| > "Looking in more detail: for the S_IFMT flags, OSX/Darwin/FreeBSD defines
| > 0xe000 as S_IFWHT (whiteout), but Solaris defines it as
| > S_IF
Gustavo Carneiro writes:
> On Fri, Jun 21, 2013 at 8:20 PM, Steven D'Aprano wrote:
>> -1 Reading the Python source code is a very good way for beginner
>> programmers to learn about things like this.
> On the other hand, it is counter-productive to learn about code
> that is conceptually _
On 20Jun2013 08:35, Benjamin Peterson wrote:
| 2013/6/20 Charles-François Natali :
| > 2013/6/20 Thomas Wouters :
| >> If the .py file is going to be wrong or incomplete, why would we want to
| >> keep it -- or use it as fallback -- at all? If we're dead set on having a
| >> .py file instead of re
26 matches
Mail list logo
