Re: [Python-Dev] Sharing expat instances

[Chris Lambacher]

Py2exe manages to load .pyd files and dlls from zip.  Apparently they have
written an alternate dll loader that does not need the file to be on the file
system.  This is used for single file apps.

I don't know if it is possible to write a portable Unix equivalent for .so
files.

-Chris

P.S.  I think it is standard practice to do an introduction on first post to
pydev.  I have been lurking on the Dev list for about a year.  I recently
completed my masters thesis which used Python extensively.  I am helping to
promote the adoption of Python for various tasks at my place of work. 


On Wed, Dec 14, 2005 at 01:15:49PM -0500, Barry Warsaw wrote:
> On Wed, 2005-12-14 at 09:56 -0800, Scott David Daniels wrote:
> 
> > One good reason for this is that the .pyd's or .so's cannot necessarily
> > be used from zip files
> 
> When you say "cannot necessarily", are the situations where they can be
> imported from zip files?  I thought the answer to that was always "no".
> 
> -Barry
> 



> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/lambacck%40computer.org

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Automated Python testing (was Re: status of development documentation)

[Chris Lambacher]

On Sun, Dec 25, 2005 at 12:54:32PM -0500, Tim Peters wrote:
> This really helps at Zope Corp.  One downside is that we seem unable
> to get an in-house Windows buildbot slave to work reliably, and so far
> don't even know whether that's because of Windows, the buildbot code,
> or flakiness in our internal network.  It seems quite reliable on
> Linux, though.

At work we build both py2exe'd apps and Visual C++ apps on windows with
buildbot with no issues.  The only problem we has was when we were first
setting it up, it was not clear that you need to explicitly tell twistd to use
the win32 reactor.

-Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion

[Chris Lambacher]

I theory Subversion should allow you to be more secure.  CVS has a very
limited concept of security and for the most part you need to rely on SSH.
Subversion makes use of Apache as one of its server options.  Any
authentication method you can use in Apache 2 you can use for Subversion.
Once Apache does the authentication, Subversion allows fairly fine grained
access control.  SSL can be used for encrypting communication.

Note that there are sites like Sourceforge that do provide Subversion hosting
to open source projects.  I don't know enough about them to be able to
recommend any.

-Chris


On Thu, Jul 28, 2005 at 01:20:14PM -0700, Guido van Rossum wrote:
> On 7/28/05, "Martin v. L?wis" <[EMAIL PROTECTED]> wrote:
> > I'd like to see the Python source be stored in Subversion instead
> > of CVS, and on python.org instead of sf.net. To facilitate discussion,
> > I have drafted a PEP describing the rationale for doing so, and
> > the technical procedure to be performed.
> 
> In principle I'm +1 on this (both aspects). I don't know enough to
> understand all the subtleties.
> 
> I hope we're correctly estimating the effort required to manage the
> server and the users. Managing users is especially important -- if a
> user is compromised (as has happened in the past for python.org users)
> the whole repository is compromised. Now this could happen to SF users
> too, but I'm not sure that we know all the tricks in the book to
> prevent attacks; SF has been doing this for years and that's an aspect
> of SF that I trust (I think I've heard that they have even modified
> their SSH server to be stricter).
> 
> -- 
> --Guido van Rossum (home page: http://www.python.org/~guido/)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/lambacck%40computer.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using SCons for cross-compilation

[Chris Lambacher]

On Thu, Nov 09, 2006 at 04:42:48PM +0100, David Boddie wrote:
> On Thu Nov 9 07:45:30 CET 2006, Anthony Baxter wrote:
> 
> > On Thursday 09 November 2006 16:30, Martin v. Löwis wrote:
> > > Patch #841454 takes a stab at cross-compilation
> > > (for MingW32 on a Linux system, in this case),
> > > and proposes to use SCons instead of setup.py
> > > to compile extension modules. Usage of SCons
> > > would be restricted to cross-compilation (for
> > > the moment).
> > >
> > > What do you think?
> > 
> > So we'd now have 3 places to update when things change (setup.py, PCbuild 
> > area, SCons)? How does this deal with the problems that autoconf has with 
> > cross-compilation? It would seem to me that just fixing the extension 
> > module 
> > building is a tiny part of the problem... or am I missing something?
> 
> I've been working on adding cross-compiling support to Python's build system,
> too, though I've had the luxury of building on Linux for a target platform
> that also runs Linux. Since the build system originally came from the GCC
> project, it shouldn't surprise anyone that there's already a certain level
> of support for cross-compilation built in. Simply setting the --build and
> --host options is a good start, for example.
> 
> It seems that Martin's patch solves some problems I encountered more cleanly
> (in certain respects) than the solutions I came up with. Here are some
> issues I encountered (from memory):
> 
>  * The current system assumes that Parser/pgen will be built using the
>compiler being used for the rest of the build. This obviously isn't
>going to work when the executable is meant for the target platform.
>At the same time, the object files for pgen need to be compiled for
>the interpreter for the target platform.
> 
>  * The newly-compiled interpreter is used to compile the standard library,
>run tests and execute the setup.py file. Some of these things should
>be done by the interpreter, but it won't work on the host platform.
>On the other hand, the setup.py script should be run by the host's
>Python interpreter, but using information about the target interpreter's
>configuration.
> 
>  * There are various extensions defined in the setup.py file that are
>found and erroneously included if you execute it using the host's
>interpreter. Ideally, it would be possible to use the target's
>configuration to disable extensions, but a more configurable build
>process would also be welcome.
> 
This pretty much covers the difficulties I encountered.  For what it's worth,
my experiences with Python 2.5 are documented here:


I am also interested in pursuing solutions that make it easier to both build
python and third party extensions in cross compile environment.

> I'll try to look at Martin's patch at some point. I hope these observations
> and suggestions help explain the current issues with the build system when
> cross-compiling.
> 
> David
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/chris%40kateandchris.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Using SCons for cross-compilation

[Chris Lambacher]

On Thu, Nov 09, 2006 at 01:15:15PM -0600, [EMAIL PROTECTED] wrote:
> 
> Martin> In any case, the patch being contributed uses SCons. If people
> Martin> think this is unmaintainable, this is a reason to reject the
> Martin> patch.
> 
> Could SCons replace distutils?
If SCons replaced Distutils would SCons have to become part of Python?  Is
SCons ready for that?  What do you do about the existing body 3rd party
extensions that are already using Distutils?  

Think of the resistance to the, relatively minor, that Setuptools made to the
way Distutils works.

I think a better question is what about Distutils hinders cross-compiler
scenarios and how to we fix those deficiencies?

-Chris
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum Eccentricities

[Chris Lambacher]

On Sun, Sep 22, 2013 at 10:41 PM, Zero Piraeus  wrote:

> I may be misunderstanding the use case given in the issue,
>

To clarify the use case, since it is my bug, this is so that the enum
values are always available for comparison. The exact use case is in Django
templates where a value comes from the database. If you want to compare you
either have to use __class__ which I would say is a code smell, or you have
to provide the Enum class. The code we are using for this is open source
http://github.com/tindie/django-tidyenum. An example of how this will be
used in practice is:

{% if object.state == object.state.completed %}
  some html
{% endif %}


> but it seems
> to me that having to use
>
> Color.red.__class__.blue
>
> (what is being complained about in the issue), while not exactly pretty,
> makes a lot more semantic sense than
>
> Color.red.blue
>
> ... which is just bizarre.
>

Any more bizarre than any other class that has properties of it's own type?

  a = 0
  a.real.numerator.real.numerator

It is only weird because we are not used to seeing classes where the
properties are instances of the class. I am not a core developer, but I
have been programming in Python for more than 10 years, and I (and the
other similarly experienced developers I work with) found that not having
access to the class level properties was weird (yes I am aware that they
are not actually class level properties but everywhere else Enum works hard
to make it look like they are. See for instance the __dir__ method:
http://hg.python.org/cpython/file/ed011b0d7daf/Lib/enum.py#l242).

-Chris

-- 
Christopher Lambacher
ch...@kateandchris.net
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Status of packaging in 3.3

[Chris Lambacher]

Nick Coghlan  gmail.com> writes:

> 
> The Python community covers a broad spectrum of use cases, and I
> suspect that's one of the big reasons packaging can get so contentious
> - the goals end up being in direct conflict. Currently, I've
> identified at least half a dozen significant communities with very
> different needs (the names aren't meant to be all encompassing, just
> good representatives of each category, and many individuals will span
> multiple categories depending on which hat they're wearing at the
> time):
> 

One set of users not covered by your list is people who need to Cross-Compile
Python to another CPU architecture (i.e. x86 to ARM/PowerPC) for use with 
embedded computers. Distutils does not handle this very well. If you want a 
recent overview of what these users go through you should see my talk from 
PyCon 2012: 
http://pyvideo.org/video/682/cross-compiling-python-c-extensions-for-embedde

-Chris

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] datetime nanosecond support

[Chris Lambacher]

On Tue, Jul 24, 2012 at 9:46 PM, Guido van Rossum  wrote:

> I didn't read the entire bug, but it mentioned something about storing
> datetimes in databases. Do databases support nanosecond precision?
>

MS SQL Server 2008 R2 has the datetime2 data type which supports 100
nanosecond (.1 microsecond) precision:
http://msdn.microsoft.com/en-us/library/bb677335(v=sql.105)

PostgreSQL does 1 microsecond:
http://www.postgresql.org/docs/8.0/static/datatype-datetime.html

If I am reading this correctly the Oracle TIMESTAMP type allows up to 9
digits of fractional seconds (1 nanosecond):
http://docs.oracle.com/cd/B19306_01/server.102/b14195/sqlqr06.htm#r9c1-t3

-Chris

-- 
Christopher Lambacher
ch...@kateandchris.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Distutils] Is is worth disentangling distutils?

[Chris Lambacher]

You can already cross compile with distutils, though it is not exactly easy:
http://pyvideo.org/video/682/cross-compiling-python-c-extensions-for-embedde

-Chris


On Fri, Dec 14, 2012 at 4:51 PM, Antonio Cavallo wrote:

> It is not that complex... What's ahead is even more complex.
>
>
>
>
>
> Lennart Regebro wrote:
>
>> On Fri, Dec 14, 2012 at 9:49 AM, Antonio Cavallo
>>   wrote:
>>
>>> My requirements would quite simple:
>>>   2. cross compiling
>>>
>>
>> That is *not* a simple requirement.
>>
>> //Lennart
>>
> __**_
> Distutils-SIG maillist  -  distutils-...@python.org
> http://mail.python.org/**mailman/listinfo/distutils-sig
>



-- 
Christopher Lambacher
ch...@kateandchris.net
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com