Glenn Linderman wrote:
> Thanks for the explanation. Brett mentioned something like runpy vs
> import using different techniques. Which is OK, I guess, but if the
> command line/runpy can do it, the importer could do it. Just a matter
> of desire and coding. Whether it is worth pursuing further
On approximately 2/27/2010 5:25 PM, came the following characters from
the keyboard of Greg Ewing:
Glenn Linderman wrote:
What I did was:
python -m test
ren test.pyc foo.py
foo.py
and it worked.
Source files mentioned on the command line aren't required to
have a .py extension. I think what
Floris Bruynooghe wrote:
(But even then I'm not
convinced that would double the stat calls for normal users, only for
those who only ship .pyc files)
It would increase the number of stat calls for normal
users by 50%. You would need to look for a .pyc in the
source directory, then .py in the so
Le Sun, 28 Feb 2010 01:25:38 +,
Michael Foord a écrit :
>
> Well if we'd *never* had this feature this argument would be very
> strong indeed. On the other hand if we want them to switch to Python
> 3 - but by the way we cut one of the features you rely on, but don't
> worry all you have to d
Meador Inge wrote:
Even with the user-defined precision capabilities of the 'Decimal'
class? In other words, can I create an instance of a 'Decimal' that
behaves (in all operations: arithmetic, comparison, etc...) exactly as
the extended double precision type offered by a given machine?
It'
On 28/02/2010 01:22, Antoine Pitrou wrote:
Le Fri, 26 Feb 2010 14:29:03 -0800, Guido van Rossum a écrit :
Byte-code only wasn't always supported. We added it knowing full well it
had all those problems (plus, it locks in the Python version), simply
because a certain class of developers won't
Le Fri, 26 Feb 2010 14:29:03 -0800, Guido van Rossum a écrit :
>
> Byte-code only wasn't always supported. We added it knowing full well it
> had all those problems (plus, it locks in the Python version), simply
> because a certain class of developers won't stop asking for it. Their
> users are ap
Glenn Linderman wrote:
What I did was:
python -m test
ren test.pyc foo.py
foo.py
and it worked.
Source files mentioned on the command line aren't required to
have a .py extension. I think what's happening is that the
interpreter ignores the filename altogether in that case and
examines the c
Guido van Rossum wrote:
Their users are apparently too dumb to decode bytecode but smart
enough to read source code, even if they don't understand it, and this
knowledge could hurt them.
I think it's like putting a lock on your door. It won't
stop anyone who's determined to get in, but it make
Steven D'Aprano writes:
> Personally, I can't imagine ever wanting to ship a .pyc module without
> the .py, but since Python already gives people the opportunity to shoot
> themselves in the foot, meh, we're all adults here.
Not sure I've seen it mentioned in this thread, but for myself, I've
On Sat, Feb 27, 2010 at 10:56:13AM -0500, Barry Warsaw wrote:
> On Feb 26, 2010, at 10:59 PM, Michael Foord wrote:
>
> >There are several companies who currently ship bytecode only. (There was
> >someone on the IronPython mailing list only last week asking if
> >IronPython could support pyc file
Meador Inge schrieb:
> On Fri, Feb 26, 2010 at 4:08 PM, Greg Ewing
> wrote:
>
>> Meador Inge wrote:
>>
>> 3. Using Decimal keeps the desired precision,
>>>
>>
>> Well, sort of, but then you end up doing arithmetic in
>> decimal instead of binary, which could give different
>> results.
>>
>
> Ev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
> On Feb 26, 2010, at 02:55 PM, Brett Cannon wrote:
>
>> Here is a question for Barry to think about if he decides to move forward
>> with all of this: would mixed support for both bytecode-only and
>> source/bytecode be required f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ian Bicking wrote:
> The one issue I thought would be resolved by not easily allowing
> .pyc-only distributions is the case when you rename a file (say
> module.py to newmodule.py) and there is a module.pyc laying around,
> and you don't get the Import
On Fri, Feb 26, 2010 at 4:08 PM, Greg Ewing wrote:
> Meador Inge wrote:
>
> 3. Using Decimal keeps the desired precision,
>>
>
> Well, sort of, but then you end up doing arithmetic in
> decimal instead of binary, which could give different
> results.
>
Even with the user-defined precision capabi
On Feb 26, 2010, at 05:11 PM, Guido van Rossum wrote:
>Barry's PEP would fix this even if we kept supporting .pyc-only files:
>the lingering .pyc files will be in the __pycache__ directory which is
>*not* searched -- only .pyc files directly in the source directory
>will be found -- where the PEP
On Feb 26, 2010, at 02:55 PM, Brett Cannon wrote:
>Here is a question for Barry to think about if he decides to move forward
>with all of this: would mixed support for both bytecode-only and
>source/bytecode be required for the same directory, or could it be one or
>the other but not both? Differi
On Feb 26, 2010, at 02:29 PM, Guido van Rossum wrote:
>Byte-code only wasn't always supported. We added it knowing full well
>it had all those problems (plus, it locks in the Python version),
>simply because a certain class of developers won't stop asking for it.
>Their users are apparently too du
On Feb 26, 2010, at 08:30 PM, Ron Adam wrote:
>It does not make sense (to me) to have byte code only modules and packages
>in python's lib directory. The whole purpose (as far as I know) is for
>modules and packages located there to be shared. And as such, the source
>file becomes a source of
On Feb 26, 2010, at 10:59 PM, Michael Foord wrote:
>There are several companies who currently ship bytecode only. (There was
>someone on the IronPython mailing list only last week asking if
>IronPython could support pyc files for this reason). For many
>pointy-haired-bosses 'some' protection is
On Feb 28, 2010, at 01:38 AM, Nick Coghlan wrote:
>I think the use case of "keep the user from fiddling casually with our
>application" is a valid one.
Doesn't the existing support for zipimport satisfy that use case already, and
probably better so?
Heck you can even name your zip file "applicat
Steven D'Aprano wrote:
> On Sat, 27 Feb 2010 09:09:26 am Brett Cannon wrote:
>> I think it's almost a dis-service to support bytecode-only
>> files as it leads people who are misinformed or simply don't take the
>> time to understand what is contained in a .pyc file into a false
>> sense of securit
Glenn Linderman wrote:
> But if the technique can work from the command line, it seems the
> same technique could be re-used in the importer.
Not really - we only get away with the fun and games at execution time
because __main__ is a bit special (and always has been). Those tricks
would be a lot
Brett Cannon wrote:
> On Fri, Feb 26, 2010 at 20:08, Glenn Linderman I'm not sure why what you did is different than what I did,
>
>
> -M uses runpy which is not directly equivalent to importing.
It's actually execution which is different from importing. Direct
execution doesn't care about
> "Steven" == Steven D'Aprano writes:
Steven> For what it's worth, I have compiled a list of between 14 and 27
Steven> implementations of Python, depending on how conservative you are
Steven> at defining "implementation".
Steven> I then went to the wiki and discovered my list
25 matches
Mail list logo
