Le 10/06/2014 21:30, Nikolaus Rath a écrit :
For me, having __del__ call close() does not qualify as a reasonable
default implementation unless close() is required to be idempotent
(which one could deduce from the documentation if one tries to, but it's
far from clear).
close() should indeed b
On 2014-06-11 02:30, Nikolaus Rath wrote:
Hello,
I recently noticed (after some rather protacted debugging) that the
io.IOBase class comes with a destructor that calls self.close():
[0] nikratio@vostro:~/tmp$ cat test.py
import io
class Foo(io.IOBase):
def close(self):
print('clos
Hello,
I recently noticed (after some rather protacted debugging) that the
io.IOBase class comes with a destructor that calls self.close():
[0] nikratio@vostro:~/tmp$ cat test.py
import io
class Foo(io.IOBase):
def close(self):
print('close called')
r = Foo()
del r
[0] nikratio@vostro
On Tue, Jun 10, 2014 at 9:30 AM, Steve Dower
wrote:
>
> I ran a quick test with profile-guided optimization (PGO, pronounced
> "pogo"), which has supposedly been improved since VC9, and saw a very
> unscientific 20% speed improvement on pybench.py and 10% size reduction in
> python35.dll. I'm not
Martin v. Löwis wrote:
> Am 10.06.14 18:30, schrieb Steve Dower:
>> I ran a quick test with profile-guided optimization (PGO, pronounced
>> "pogo"), which has supposedly been improved since VC9, and saw a very
>> unscientific 20% speed improvement on pybench.py and 10% size
>> reduction in python35
Am 10.06.14 18:30, schrieb Steve Dower:
> I ran a quick test with profile-guided optimization (PGO, pronounced
> "pogo"), which has supposedly been improved since VC9, and saw a very
> unscientific 20% speed improvement on pybench.py and 10% size
> reduction in python35.dll. I'm not sure what we us
Am 07.06.14 17:38, schrieb Steve Dower:
> One more possible concern that I just thought of is the availability of
> the build tools on Windows Vista and Windows 7 RTM (that is, without
> SP1). I'd have to check, but I don't believe anything after VS 2012 is
> supported on Vista and it's entirely po
Am 07.06.14 01:01, schrieb Steve Dower:
> We keep the VS 2010 files around and make sure they keep working.
> This is the biggest risk of the whole plan, but I believe that
> there's enough of a gap between when VS 14 is planned to release
> (which I know, but can't share) and when Python 3.5 is pl
2014-06-10 18:30 GMT+02:00 Steve Dower :
> I ran a quick test with profile-guided optimization (PGO, pronounced "pogo"),
> which has supposedly been improved since VC9, and saw a very unscientific 20%
> speed improvement on pybench.py and 10% size reduction in python35.dll. I'm
> not sure what w
On 6/10/2014 2:51 PM, Hasan Diwan wrote:
From the csv module pydoc:
"The optional "dialect" parameter is discussed below"
The discussion is actually above the method. Present in 2.7.6.
Bug reports should be posted on the tracker rather than sent here. Short
doc reports like this can be sent
On Tue, Jun 10, 2014 at 2:04 PM, Ben Hoyt wrote:
>>> To solve this problem, what do people think about adding an
>>> "st_winattrs" attribute to the object returned by os.stat() on
>>> Windows?
>>
>> +1 to the idea, whatever the exact implementation.
>
> Cool.
>
> I think we should add a st_winattr
>> To solve this problem, what do people think about adding an
>> "st_winattrs" attribute to the object returned by os.stat() on
>> Windows?
>
> +1 to the idea, whatever the exact implementation.
Cool.
I think we should add a st_winattrs integer attribute (on Windows) and
then also add the FILE_A
>From the csv module pydoc:
"The optional "dialect" parameter is discussed below"
The discussion is actually above the method. Present in 2.7.6. -- H
--
Sent from my mobile device
Envoyé de mon portable
___
Python-Dev mailing list
Python-Dev@python.org
> Antoine Pitrou wrote:
> Le 10/06/2014 12:30, Steve Dower a écrit :
>>
>> I ran a quick test with profile-guided optimization (PGO, pronounced
>> "pogo"), which has supposedly been improved since VC9, and saw a very
>> unscientific 20% speed improvement on pybench.py and 10% size reduction in
>> p
>> I wonder how a hybrid approach would work? Use a dynamically-created
>> class, but then construct the __new__ method using exec and inject it
>> into the new class. As far as I can see, it's only __new__ that benefits
>> from the exec approach.
>>
>> Anyone tried this yet? Is it worth an expe
Le 10/06/2014 12:30, Steve Dower a écrit :
I ran a quick test with profile-guided optimization (PGO, pronounced
"pogo"), which has supposedly been improved since VC9, and saw a very
unscientific 20% speed improvement on pybench.py and 10% size reduction
in python35.dll. I'm not sure what we use
On Tue, Jun 10, 2014 at 12:17 PM, Ethan Furman wrote:
> On 06/09/2014 09:02 PM, Ben Hoyt wrote:
>> To solve this problem, what do people think about adding an
>> "st_winattrs" attribute to the object returned by os.stat() on
>> Windows?
>
>
> +1 to the idea, whatever the exact implementation.
Agr
On 06/09/2014 09:02 PM, Ben Hoyt wrote:
To solve this problem, what do people think about adding an
"st_winattrs" attribute to the object returned by os.stat() on
Windows?
+1 to the idea, whatever the exact implementation.
--
~Ethan~
___
Python-Dev
For anyone who is interested in more details on the CRT changes, there's a blog
post from my colleague who worked on most of them at
http://blogs.msdn.com/b/vcblog/archive/2014/06/10/the-great-crt-refactoring.aspx
I wanted to call out one section and add some details:
In order to unify thes
On 10 June 2014 13:58, Ben Hoyt wrote:
> So stat.FILE_ATTRIBUTES_HIDDEN and the like?
Yep. (Maybe WIN_FILE_ATTRIBUTES_HIDDEN, but the Unix ones don't have
an OA name prefix, so I'd go with your original).
Paul
___
Python-Dev mailing list
Python-Dev@pyt
On 10 June 2014 23:05, R. David Murray wrote:
> On Tue, 10 Jun 2014 19:07:40 +1000, Nick Coghlan wrote:
>> I believe it's a space/speed trade-off, so I'd be surprised if it made
>> sense for CPython in general. There are also some behavioural differences
>> when it comes to handling syntax errors
On Tue, 10 Jun 2014 19:07:40 +1000, Nick Coghlan wrote:
> On 10 Jun 2014 18:41, "Paul Moore" wrote:
> >
> > On 10 June 2014 08:36, Nick Coghlan wrote:
> > > The standard implementation of run_path reads the whole file into
> > > memory, but MicroPython would be free to optimise that and do
> > >
> The stat module exposes a load of constants - why not add the
> (currently known) ones there? Finding the values of Windows constants
> if you don't have access to the C headers can be a pain, so having
> them defined *somewhere* as named values is useful.
So stat.FILE_ATTRIBUTES_HIDDEN and the
On 10 June 2014 13:19, Ben Hoyt wrote:
> Because these are fixed-forever constants, I suspect in library code
> and the like people would just KISS and use an integer literal and a
> comment, avoiding the import/constant thing:
The stat module exposes a load of constants - why not add the
(curren
>> if hasattr(st, 'st_winattrs') and st.st_winattrs &
>> FILE_ATTRIBUTE_HIDDEN:
>
> That could be written more succinctly as:
>
> if getattr(st, 'st_winattrs', 0) & FILE_ATTRIBUTE_HIDDEN:
>
>> return True
>> return False
Yes, good call. Or one further:
return getattr(
> > FILE_ATTRIBUTE_HIDDEN = 2 # constant defined in Windows.h
> >
> > if hasattr(st, 'st_winattrs') and st.st_winattrs &
> > FILE_ATTRIBUTE_HIDDEN:
>
> I don't like such API, it requires to import constants, use masks, etc.
>
> I would prefer something like:
>
>if st.win_hidden: ...
>
> O
On 2014-06-10 05:02, Ben Hoyt wrote:
[snip]
FILE_ATTRIBUTE_HIDDEN = 2 # constant defined in Windows.h
def is_hidden(path):
if startswith(os.path.basename(path), '.'):
return True
st = os.stat(path)
if hasattr(st, 'st_winattrs') and st.st_winattrs & FILE_ATTRIBUTE_HIDDEN
2014-06-10 6:02 GMT+02:00 Ben Hoyt :
> To solve this problem, what do people think about adding an
> "st_winattrs" attribute to the object returned by os.stat() on
> Windows?
> (...)
> FILE_ATTRIBUTE_HIDDEN = 2 # constant defined in Windows.h
>
> if hasattr(st, 'st_winattrs') and st.st_winattr
On 10 Jun 2014 18:41, "Paul Moore" wrote:
>
> On 10 June 2014 08:36, Nick Coghlan wrote:
> > The standard implementation of run_path reads the whole file into
> > memory, but MicroPython would be free to optimise that and do
> > statement by statement execution instead (while that will pose some
On 10 June 2014 08:36, Nick Coghlan wrote:
> The standard implementation of run_path reads the whole file into
> memory, but MicroPython would be free to optimise that and do
> statement by statement execution instead (while that will pose some
> challenges in terms of handling encoding cookies, f
On 10 June 2014 05:02, Ben Hoyt wrote:
> To solve this problem, what do people think about adding an
> "st_winattrs" attribute to the object returned by os.stat() on
> Windows?
+1. Given the precedent of Linux- and OS X-specific attributes, this
seems like a no-brainer to me.
Paul
__
On 10 June 2014 12:23, Paul Sokolovsky wrote:
> 1. It hampers interactive mode - instead of short and easy to type
> execfile("file.py") one needs to use exec(open("file.py").read()). I'm
> sure that's not going to bother a lot of people - after all, the
> easiest way to execute a Python file is t
32 matches
Mail list logo
